Clean up dependencies in brackets.js #10596

Merged
merged 3 commits into from May 20, 2015

Projects

None yet

2 participants

@MarcelGerber
Member

For case 2 of #1783.

@MarcelGerber MarcelGerber changed the title from Brackets js dependencies to Clean up dependencies in brackets.js Feb 14, 2015
@busykai busykai commented on the diff May 13, 2015
src/brackets.js
@@ -162,50 +153,50 @@ define(function (require, exports, module) {
// in the modules since they would run in context of the unit test window,
// and would not have access to the app html/css.
brackets.test = {
- CodeHintManager : CodeHintManager,
- CodeInspection : CodeInspection,
- CommandManager : CommandManager,
- Commands : Commands,
+ CodeHintManager : require("editor/CodeHintManager"),
@busykai
busykai May 13, 2015 Member

Why another require is preferable? Does it solve any issue at all?

@MarcelGerber
MarcelGerber May 13, 2015 Member

I removed the require above since we should only require module over there that we actually need in our code, for example for calling their methods.
The only occurence of CodeHintManager, though, is here in brackets.test.

See #1783 (case 2) for more details.

@busykai
busykai May 13, 2015 Member

It does not quite explain all the changes. LanguageManager is loaded twice via require, for example.

@MarcelGerber
MarcelGerber May 13, 2015 Member

Oh, I see. This PR is 3 months old, so I don't exactly know the initial motivation, but I think it might be that this just looks cleaner to me, than having a mixture of requires and variable references.

@busykai
busykai May 14, 2015 Member

OK. Now I see. Not going to argue aesthetics. It may improve readability for this one case, but I prefer variables since they can be linted and not get back at you at runtime. Technically, there's a negligible difference and the code is executed once. So if you want to, you can merge it with master and we can merge it back in. If not, let's close it.

@MarcelGerber
Member

@busykai Merged with master.

@busykai
Member
busykai commented May 14, 2015

@MarcelGerber, it works OK. The only comment I have is: I'd also move the CodeMirror load/global def lines 104-114 to before line 47 (right before all the CodeMirror plugins are loaded). First of all, these lines create a global; secondly it makes sense (for readability) to load the module itself before loading its plugins. Tried the change, it causes no problems. Does it make sense to you?

@MarcelGerber
Member

The issue with that is, though, that these lines need DeprecationWarning, which is defined later on (and thus causes a JSLint error).

The only thing we could do is load CodeMirror before line 47 and then create the global, deprecated object afterwards, but that would then be out of context.

@busykai
Member
busykai commented May 18, 2015

@MarcelGerber, you're right. However, I think we could well load DeprecationWarning at the very beginning (using separate var). It's a utility and does not really belong among other "functional" modules. What do you think?

@MarcelGerber
Member

I'm not too fond about that. We've pretty much always kept the requires in one block and I don't like the idea of making an exception just for this module.

@busykai
Member
busykai commented May 20, 2015

@MarcelGerber, ok! This looks good to me. It solves the purpose that you outline in the PR description. Merging.

@busykai busykai merged commit 19f9b43 into adobe:master May 20, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@MarcelGerber MarcelGerber deleted the MarcelGerber:brackets-js-dependencies branch May 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment