Too high granularity and fragmentation... Your decision?

[Andrew Gaydenko]

At the moment I have require.js/r.js managed project and am thinking to use something more modular :) So, am reading component docs...
Say, I have a project subdirectory with:

/users
    Users.js
    users.html
    UserDigest.js
    userDigest.html
    Discounts.js
    discounts.html

To use components I'm forced to divide this subdirectory into three ones (every js has something to export):

/users
    Users.js
    users.html
    component.json
/userDigest
    UserDigest.js
    userDigest.html
    component.json
/discounts
    Discounts.js
    discounts.html
    component.json

This way I would get two bad things:

1. related code is fragmented,
2. crazy degree of granularity.

What is the component way for the case?

[rogerz]

I think it is up to you to whether package them all as a component or separately. 

If these are always reused together, you may put just one component.json to include them all. 

Otherwise, if they are to be reused separately, then it is reasonable to split into several components.

--
You received this message because you are subscribed to the Google Groups "component" group.
To unsubscribe from this group and stop receiving emails from it, send an email to componentjs...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Andrew Gaydenko]

On Tuesday, January 7, 2014 2:36:54 PM UTC+4, Rogerz Zhang wrote:

I think it is up to you to whether package them all as a component or separately. 

If these are always reused together, you may put just one component.json to include them all. 

Otherwise, if they are to be reused separately, then it is reasonable to split into several components.

Two of js files returns constructor functions used in some other module (and can be called many times as far as it is SPA). The third is used by one of the two first. So, I can not understand how to wrap all three js into a single component.

[rogerz]

If I understand right, User and Discount will be reused but UserDigest is used only by User. Then I would prefer to organize them as

* User

  * require UserDigest with relative path inside the component or as local dependency

* Discount

[Andrew Gaydenko]

So, to summarize, it is impossible present these three files (with their html files) as a single component, is it?

[rogerz]

If you want them to be together but used separately. You still can just export them in one js file. e.g.

module.exports = {

   user: require('./user.js'),

   userDigest: require('./userDigest.js')

   discount: require('./discount.js')

}

On Tue, Jan 7, 2014 at 8:50 PM, Andrew Gaydenko <andrew....@gmail.com> wrote:

So, to summarize, it is impossible present these three files (with their html files) as a single component, is it?

--

[Andrew Gaydenko]

On Tuesday, January 7, 2014 5:57:22 PM UTC+4, Rogerz Zhang wrote:

If you want them to be together but used separately. You still can just export them in one js file. e.g.

module.exports = {

   user: require('./user.js'),

   userDigest: require('./userDigest.js')

   discount: require('./discount.js')

}

Rogerz, thanks for the clarification! Yes, I have guessed it is possible to expose them all under umbrella of additional js.

[William Casarin]

After using component for awhile I find components that aren't a single file lead down a slippery slope of bloat and ugliness. These are the local components currently in one of our larger component applications:

https://gist.github.com/jb55/38d2f943132394fdcd89

models, views and templates are in their own components. Much cleaner for our build scripts (we use redo to compile our jade and coffeescript to js before component build runs).

The key to this is to have a script that facilitates creating local components from a skeleton, so it isn't tedious creating them. For instance, we use a script ./create_component <name> [<type>] that creates a local component from a skeleton and replaces the name in the component.json. This could be created as a component subcommand which I may get around to sometime...

[Ian Storm Taylor]

+1 to what William said. 

Our local components look like this: https://gist.github.com/ianstormtaylor/8423837 — And then each page of our site is now broken in separate Express apps and a separate component build. Each of these subapps has their own private /lib folder, for example the signup app’s folder has these component in it: https://gist.github.com/ianstormtaylor/8423853

But we’re even going a step further now, and the shared /lib folder between apps is actually causing problems because all of those local components are unversioned. So the new policy we’re going with is anything that is shared across apps needs to be in its own repo on GitHub and well use .netrc (or a private registry once the public one is built) to manage downloading them all. That way you get to share things across builds without them being unversioned.

My new war (after making everything into small components) is to make sure everything that is shared between two places is versionable, otherwise you’re still playing the tightly coupled “update this everywhere it’s used” game.

--

[Nami Doc]

> The key to this is to have a script that facilitates creating local components from a skeleton, so it isn't tedious creating them. For instance, we use a script ./create_component <name> [<type>] that creates a local component from a skeleton and replaces the name in the component.json. This could be created as a component subcommand which I may get around to sometime...

Agreed. That's a big part, we should have it in component(1).

[William Casarin]

It kind of already does with component create -l lib/name

The only reason I'm not using it is because I'd rather have it not prompt for my use case and I have a few extra files in my skeleton. Maybe a component skel command with some of these features would be the way to go here.

--