App Structure (Organizing View and Control)

[bdcannon]

What goes where? We've been shifting around some code from place to place in the app structure. I personally think js code that is modifying the view but not mutating data should remain in the .jade file for the view. Or as @joshbaird suggested, creating a new directory under javascripts called views or viewjs.

[joshbaird]

I like having jade code in jade. and js in js. Does not tie one to the other. we can switch out the jade template engine. or even reuse some view stuff... Organizing it so you know what JS is for views and what JS is for data control is a suggestion. make a directory under javascripts called 'views' and put it there. Or another idea pre-pend the js file with view. so the index js code would be named. viewindex.js. then they can all live in the same directory and you know all view*.js code is for views. Other thoughts?

[HarderBetterFasterStronger]

Yep, keeping the js and jade separate makes sense. If we don't want a js file, we should just not include it in the of the jade file. As far as organization goes, not really sure.. All for separation of view and control though, just as long as we don't put the js in the jade. That, for me, is a no no.

[bdcannon]

Why are you against putting js in a jade file. jade == js. I'm perfectly fine with seperating them out. But from my understanding for having an MVC design pattern is to group your functionality together. Keep stuff for the view in spot, keep stuff for mutating data and shit in one place, and you db somewhere else. Separating stuff because they're different languages creates headaches even though they're for the same functional group (view or whatever). People have to start hunting around for code in the structure.

[joshbaird]

My editor does not like it haha. I can add .jade to use js syntax, and then it will like it. Maybe for me its because I think .jade is a template. and .js is code. You can swap out templates and keep the code. But you guys know more Node and JS then me. So I will work around whatever you guys think. What do most people do? is there some kind of standard? Whatever the choice is we need to for sure group the code, in the same file, or name or group or something...

[HarderBetterFasterStronger]

I like to keep js together to keep it portable. If we put inline with html sometimes you lose track of dependencies and you might duplicate same javascript code across made html files. Then merging them back in to a js file is a pain because you might break something that you specifically changed for one function even though you didn't change the function name when you made the specific modification. Then you have same js over and over again each having its own modification and it gets bad, fast.

The second reason is the one josh mentioned where it becomes a pain in the ass for writing jade/js code if your editor can't understand both at same time. I use sublime text and even it can't do both in one file.

The other reason I like to keep the js separate is because from what I understand, the browser reads every line of a file when it loads it. Even comments. So when you go from one page to the next, you are always loading a huge js file if combined with the html. Taking the JS out allows us to minify the JS after we are sure it works. i.e. jquery.min.(js/css..etc)

The js that goes with the views could be put in the 'views' instead of 'public' if node.js server allows for it, permissions-wise. It might be a node exception that the public folder can be viewed and views can not. I'll check..

[HarderBetterFasterStronger]

public folder -- http://localhost:3000/javascripts/Datepair.js result: found

views folder -- http://localhost:3000/views/index.jade result: 404

jade is parsed by node, node turns it in to html and doesn't touch the public /css or /js...maybe that's our config too though

[bdcannon]

Absolutely keep it portable, but if we're having dependency issues its not because we're putting js in the view, its because we're writing bad code. Jade is templating language, you put stuff in your template for views that share common dependencies. One template for one or more views that share layout, functionality...whatever. Putting stuff into big js file and using that across your views is not using the framework correctly. Also, letting your code highlighter dictate your design choices seems bad.

It doesn't turn it into html. Html is text. Jade is text. The server sends text with a header specifying what kind of text it is. The jade engine just scours though it looking for tags that are supposed to be somethings besides the placeholder. The reason you got 404 is because this isn't an apache webserver. The only route that is publicly available is because you set the public directory to be a static directory. That means everything in there is flat. Doesn't need to be handled or parsed. If you want to get the raw.jade file you can. But you need to move the views out of the view directory.

Anyway I support moving js out of a view into a js file.

[bdcannon]

node does touch the /js /css. Those files in the public directory are static files used by the browser. To send those files, even if they are not jade, the node server must load those text files into memory to send them out. If you dig into the express code for accessing files in public directory, you'll probably see calls made the the native 'fs' module. By setting the static public directory like this

app.use(express.static(path.join(__dirname, 'public')));

you are adding a piece of middleware, which is a javascipt function called by express that has access to every request coming into the server.

[HarderBetterFasterStronger]

you have done the research, so whatever you wa t to do. Ha as long as it works!...we will definitely figure out quickly ha if we make a bad decision. Whatever works best for you guys. But if I keep reversing your commits, just know that I love you guys.

PS I won't let this discussion end professionally.

[bdcannon]

Professionally is overrated. I say the next design conversation is over beers.

[HarderBetterFasterStronger]

Or first one to talk about design (or project in general) has to take a shot