Modules for javascript files

[theq629]

Given that some of the javascript files are fairly large, I'd like to move to using some sort of modules, probably just the anonymous closure kind like

var mymodule = (function () {
  function foo() {
  }
  function bar() {
  }
  return {
    foo: foo
  }
}());

Does anyone have any objections or other ideas?

[avacariu]

No objections from me; I really like this idea. The code is fairly difficult to figure out right now, and I think modularizing it more would definitely help.

As a related idea, maybe we should try to see what code is repeated in the different files and stick it all in a lib, or utils file/module. Some code that could be in there is various ways of working with the different constraint types (countbyyear, countbyfield, etc). The queries.js file is good for defining the objects, but some helper functions in a separate file would be nice.

[KonceptGeek]

I also agree in modularizing the code as currently it is difficult to understand. :+1:

[theq629]

Ok, I'm going to start with the basic modules and maybe a more consistent objectish interface for what the various view setup functions return.

If anyone has better ideas for abstractions in general then please go ahead and suggest them. I suspect that the queries.js interface is much more complex than it needs to be, but I'm still not sure what the better query system would be.

[theq629]

Would this be a convenient time for me to do the basic modules (not any serious refactoring, just modules for namespacing)? It won't be a very significant change but it will touch a lot of code (ie all cross-file function calls).

[anoopsarkar]

yes, let's do modules and then take a look at queries.js

[theq629]

In the mwhitneyrefactoring branch I've added the simple modules as above. Modules names start with uppercase to avoid conflicts with existing variable names. I've adjusted function names to remove redundancies now that there are namespaces (eg setupMap() becomes Map.setup()). I did other minor renaming and the change for #138, but no other refactoring yet.

Configuration variables are now in the FrontendConfig module. The domain files (eg wikipediahistory_config_defaults.js) should define this module normally, and the installation settings (eg frontendsettings.js) can modify it.

I wasn't able to work out what to do in the Cluster tab that doesn't take too long for the backend to respond, so that part isn't tested properly.

How does this seem?

[anoopsarkar]

This sounds good to me but perhaps either @konceptgeek or @vlad003 can do a quick code review?

[avacariu]

I looked through the commits, and it looks great :+1:

If there are any other things that need to be renamed, we can do that as we go. It should be easier now that most of the functions are isolated.

[theq629]

Yes, I'm thinking we can now work on improving each view component separately (but hopefully coming up with better patterns and shared code). I'm planning start with improving the facet view because I would like to share code with the storyline for #141.

[KonceptGeek]

Went through the commits and it looks good :+1:

[anoopsarkar]

Should we close this issue now?

[theq629]

Yes.