backbone-boilerplate / generator-bbb

Backbone Boilerplate Yeoman generator.
MIT License
56 stars 9 forks source link

Modules encapsulating UI and data? #35

Open mulderp opened 10 years ago

mulderp commented 10 years ago

Hi @tbranyen !

If I understood correctly from the video of your Backbone talk at Backboneconf, you were advising to use separate files for the UI/View layer and the data layer.

Would this mean we would get a different way to call:

yo bbb:module <name>

e.g.

yo bbb:collection <name>

or

yo bbb:ui <name>
SBoudrias commented 10 years ago

Hi @mulderp, I've been thinking about those for a while, and I'm still unsure how I'd like to manage creating backbone objects in the generator.

Unlike more structured framework like Ember/Angular, there's very few information the generator can write to the file. Anyway, the last thing I had in mind was yo bbb:module <name> --contains=view

And then it would generate the correct object type and maybe some extra. For views, I think i'd put them this way:

module.exports = Backbone.View.extend({
  template: require("./template/name.html")
});

But for model/collection, I'm still unsure. Any suggestion or return on a similar API is warmly welcomed!

SBoudrias commented 10 years ago

Oh also, there's of course the separation of concerns in a module. So I wasn't sure if module should only generate a file, so it is used this way:

yo bbb:module slider/main
yo bbb:module slider/model

Or if calling bbb:module should generate a folder structure. (Maybe a bit like rails generate scaffhold)

Although, I think this structure is still a WIP and haven't been exactly defined yet in the BBB project. - And then also, of course, BBB is moving more away of app creation best practice and more on the tooling side of the things. So this concern may be out of scope for where Tim wanted to bring the future of BBB.

mulderp commented 10 years ago

Interesting thoughts. Well, the Rails approach is often taken as an example, but in my opinion, Backbone's model and collection belong together. My favorite way of structuring this is by looking at the original documentcloud application like here: https://github.com/documentcloud/documentcloud/blob/master/public/javascripts/model/accounts.js

Since many views need a template, and some don't, I also like the idea of having a directory 'UI' in an application, so, for my taste the critical separation is 'UI' and 'Data' . This might also be interesting to managing source code, since UI will need to change more often (= more merges), than Data does (= API is more stable).

Well, I know this breaks the concept of MVC a bit, but on the client-side things are different anyhow.

PS Sorry about the confusion of BBB and Generator-BBB, I thought they were more closely related.

SBoudrias commented 10 years ago

PS Sorry about the confusion of BBB and Generator-BBB, I thought they were more closely related.

Oh no, they are closely related. generator-BBB generate a full BBB project - with added user/productivity needed features.

I agree with you on the data part, like you I usually combine model and collection in the same file when that make sense. And their position is relative to their scope (global application or only a sub-module).

I'd like to see a demo the tree of your typical BBB application.

mulderp commented 10 years ago

So far, I am only working with medium sized projects. It is mainly:

I am recently working with Thorax, where it looks something like:

main.js (= basic setup) /views /router /templates

The Thorax generator also does a Collection and Model structure, see: https://github.com/walmartlabs/generator-thorax

Hmm.. most likely, it is a question of project evolution...

tbranyen commented 10 years ago

It's very much the future for this project. Components are a big deal and we're already seeing them used in active development. I think right now is a bit premature to formally bake anything in.

The text plugin and css plugins are not sufficient as defaults in my opinion. I want to see an excellent Lo-Dash/Underscore templating optimizer that does proper precompilation and inlining. The CSS plugin would need to build out to a separate file instead of inlining inside of the output JS build.

tbranyen commented 10 years ago

I wrote https://github.com/tbranyen/lodash-template-loader in response to the first missing piece. Looking into CSS plugins now.