idea/help: Better route(s) defining (and reusable components continuation)

Hi there. I’m just continue thinking about “reusable” components started from #266. And I got some structure and ideas.

So currently we can define only one time an array of routes, right? Using app.router. But why not add app.route method or something like that, to add routes more dynamically, it would be more flexible and will allow to define which component or page for which route is, inside from the component/page.

I’m thinking for the following thing

components/
- componentName/index.js
- componentName/model/
- componentName/model/index.js
- componentName/model/reducers.js
- componentName/model/effects.js
- componentName/model/state.js
pages/
- home.js
- about.js
elements/
- input.js
- button.js

Actually I don’t have real app so I can’t decide correctly, and there are some random thoughts in my head.

Description of above structure:

• componentName/index.js would be the view also it can be that mentioned .choo file. But really we don’t need choo files, because they limiting us for no reason. We can have local state again. In that file we will just have choo/html require at least, or we can even require more elements (from elements folder) to construct some view or layout.
• componentName/model/ - model things such as reducers and effects. It’s intentional that it is a folder. That structure is inspired by @kaktus project, where parts of the model are separated. This also allows if some view/page/other component, want to use that model - like just require('./model') (actually it won’t be recommended / correct, because they would be loaded anyway and the way they should be used is send('namespace:reducerOrEffect'))
• componentName/model/index.js just autogenerated file which is exactly like this index - just exporting state, reducers and adds namespace. Optionally it can be just more flat if someone don’t want to separate files for the model parts.

So what’s related with the router. It’s easy. Pages in another side would be more higher-level things assembling few components. So it would be useful if any page can define it’s route, so should export function that gets app argument.

example about page

module.export = function (app) {
  // assemble few components, layouts and etc
  app.route('/about', aboutPage)
}

The second thing which may should be changed is the “plugins”, that i think it should accept function, that gets app argument and returns something. So you will have instance and would have ability to add things, routes, to register components on some cache (object or array) and etc.

So later you will have client.js like this

const choo = require('choo')
const log = require('choo-log') // updated to new plugins api
// note: this not exist, but could be wrapper for choo
const app = require('choo-components')(choo({
  hooks: 'here'
}))

app.use(log())

// register components (may not make sense? not sure)
// app.use(require('components/form'))
// app.use(require('components/foobar'))
// app.use(require('components/google-maps'))

// or directly register `pages`
app.use(require('pages/home'))
app.use(require('pages/about'))

document.body.appendChild(app.start())

It’s not very clear in my mind yet, but if we change plugins API we could do better things. And every page would just add it’s route to which it should point. Also one thing to mention is that maybe app.start should “run/start” the router (pass the app.routes array for example to app.router)

---

So in short, the things may look complex and complicated, but they aren’t (everything other will be in separate wrapper lib - the things about components/pages loading and generating). The needed changes is the plugins api and add app.route to add single route to app.routes array that later is passed to app.router from the app.start

edit: It is easy to just create another method like .component instead of changing plugins api, but use is good word and make sense the plugins to be more better and still allow defining hooks.

[yoshuawuyts]

I started off with the idea of allowing each page to define their own routes but quickly realized that it allows hiding abstractions which makes for a good amount of complexity.

I feel what you’re proposing is different enough that it would require a full rewrite - something that I can encourage you to do, and given choo’s modular nature it should be very much possible to do.

Gonna close this for now tho, happy to hear how your experiments go!

[tunnckoCore]

Good and interesting question, but don’t think it is “framework” job to do this. The mentioned app.route would be something like app.routes.push(route) thing, it’s up to the user.

Also I don’t think it is protected from this as it is currently. If user/dev want to break his job it can. The core thing behind “frameworks” should be just thin sugar and helper things with thin borders. We don’t need strict rules.