Suggestions/discussion for features enabling better structured apps

[cjblomqvist]

There's a need to be able to better structure ones apps. Basically, my take on this is that you'd want to keep the following together with each component:

• styles
• views
• subcomponents

Basically, it makes sense if it's possible to specify this on each component. Take below example of a structure:
/mycomponent/index.js - my "Controller" class
/mycomponent/views/index.html - the view for mycomponent
/mycomponent/styles/index.css - the css for mycomponent
/mycomponent/components/subcomponent1/index.js - A direct subcomponent to mycomponent, only used for better structuring mycomponent (i.e. not a generic subcomponent)
/mycomponent/components/subcomponent1/... - Follows the same structure as above

To facilitate this scenario, without mycomponent being dependent on any other structure and knowing where the app is (i.e. the variable holding the created derby app), there are some missing features currently:

• One cannot specifiy where the styles are located (and possibly, one would want to be able to specify many)
• One cannot add the subcomponent without access to the app

Preferably, if Derby wants to be opiniated, this could of course be automatically done (possibly overriden by the mycomponent constructor prototype). My suggestion would also be to automatically namespace in some way. We've already discussed some alternatives and issues for CSS (and e.g. stylus) here: #477 I also made a simple plugin ( https://github.com/BBWeb/d-subcomponents ) which replaces the app.component fn which facilitates specifying subcomponents for anyone running into similar issues meanwhile something proper is thought of for Derby.

Further, it is a little bit tedious to add functionality to the app.component fn, if there are any way it can be refactored so that it is easier to modify, this might be something that'd be nice!

Anyway, I wanted to bring up some thoughts on the matter. So far this is far from a full discussion on how Derby should support devs to structure their apps, but at least it's a start. Would love to hear your thoughts either here on GitHub or in the next open source office hours (I'll try to make it, otherwise feel free to comment anyway).

[cray0000]

@cjblomqvist looks interesting.
This is how I see our goals in making the components deps working:

1. Components need to be able to depend on any other component that is in npm.
2. Dependant components that are loaded from npm should load into app only once no matter how many components depend on them
3. Incapsulation -- component should have it's own private scope to access components he depends on (but the component should still be loaded into app only once even though he can be used as a dep in other components by different private name in each component)

So it's basically the analogue of npm packages funcionality but without taking versioning into consideration. If we also want to have an ability for components to depend on different versions of the same component then the complexity drastically increases.

Without versioning we can have the structure similar to how browserify allows the "browser" field to be specified in package.json -- our system can have a section named i.e. "components" that can be either array (if we don't care about private name) or an object that maps components we specified in "dependencies" section by the private names they are going to be used in viwes of this component:

"name": "my-cool-component"
"components": {
  "bootstrap": "d-bootstrap"
},
"dependencies": {
  "d-bootstrap": "*"
}

and in the view of my-cool-component we use it like this:

<view is='bootstrap:tabs' />

if the "components" section is an array then it uses the default name of the dep components as specified in those components themselves.

Also considering that we have a guideline that everyone follows to name derby components starting with d- then instead of an additional "components" section we can just parse the "dependencies" section for all those packages that start with d-

[craigbeck]

Thanks for your contributing your issue.

We have recently been actively updating the Derby and Racer packages, and both repos are now in Typescript and published with types on npm. As we have quite a few old issues open we have made the decision to close out of date issues.

If this issue still matters to you we encourage reproducing against the current versions of the repo and opening a new issue.