Features draft

[asavin]

What it should be able to do

• [ ] reflex i[nit] [appname] - generates a fully functioning skeleton of the Reflex app
• [x] reflex s[erver] - serves the app
• [ ] reflex g[enerate] routname[s] - generates and appends new routes into the app (with appropriate views). You can pass an array of routes.
• [ ] reflex install [module name] - something about pluggable modules for the Reflex fw
• [ ] reflex scaffold - something similar to Rails, but maybe not needed at all

Ideas

• Most of the commands can very well be gulp tasks, and the user can easily ignore the whole client thingie and just use gulp (and extend whatever)
• init would generate all the necessary files, as well as run npm install and gulp, so that the app is ready to be launched with reflex server
• Hot code reload while serving the app would be very hot
• We could server the framework with a multiple examples, each of which could be installed with reflex init example [name]

Principles

• One client tool rules them all
• Easy to start making apps - the user doesn't have to know gulp or other tools, client takes a full care of the user to a certain point. Advanced users should be allowed to skip the client if they choose so, beginners should be able to rely solely on the client until they learn more about various tools and require more levels of control.
• Client tool should not hide git, but is ok to hide npm, gulp and whatever else is required to generate and start the app

[charypar]

:+1: on everything you said.

[asavin]

So I guess it's going to be an npm module, and the full journey for the first time user will be like this:

1. Go to http://nodejs.org and install Node.
2. npm install -g reflex - or whatever the name will be
3. reflex init helloworld && reflex s

[charypar]

npm install -g reflex?

[asavin]

Thanks, yes, -g

[charypar]

Just thought of an idea. Should reflex s also start a gulp watch and recompile with changes...?

[asavin]

Yeah I think it's a great idea to combine server with hot code reload.

[asavin]

One fun thing for the example app would be having responsive layout in place and different looking components that are replacing each other for each breakpoint while sharing the same data.

[asavin]

Also generate tests for UI components: props go in -> expected html comes out

[dpiatek]

What would be the difference between scaffold and generate?

[tabazevedo]

Yeah that's kind of confusing. generate should just take a parameter which defines what to generate. ie. reflex g route [path] [(optional) component]

[asavin]

@dpiatek in Rails you can generate skeleton of the app, then generate some extra models / controllers, and then scaffold views for CRUD actions on those models. What sort of things are we possibly interested in generating, apart from routes?

[asavin]

@tabazevedo assuming that componentName will always match routeName ?

[tabazevedo]

@asavin no, i meant that you can specify the component name but it defaults to matching the path. I guess path and routeName will be different though so I suppose it would be reflex g route [path] [routeName] [(optional) componentName] and by default componentName = routeName

[dpiatek]

@asavin isn't scaffold just a generator in Rails, as in rails generate scaffold? http://guides.rubyonrails.org/v3.2.13/getting_started.html#getting-up-and-running-quickly-with-scaffolding . Would nice to have one command to generate them codes.

[tabazevedo]

Yeah in Rails it just generates a model with a controller with a view (and some other misc stuff), so its a bit of shorthand.

[asavin]

Is there anything else besides routes we want to generate? I was hoping to stick with something like reflex g tweets friends profile - which would generate pages and routes for the given array of things.

(just thinking out loud)

that would generate following URL:s, root components and tests: .../tweets .../friends .../profile

...aaaaaand a navbar component with links to all those pages.

[asavin]

More potential batteries to the box:

• Support for localisation
• User authentication

[charypar]

@asavin I think eventually, we'd like to generate "state observers" too. I'm not sure what to call them, but the things that listen on the app-state and respond to changes.

[tabazevedo]

@asavin I feel like things like auth and locales are really application-specific and shouldn't be part of the cli...

[charypar]

@asavin Agree with @tabazevedo on auth and localisation. It shouldn't even be a part of the core framework. We should strive to make the plugins capable enough that these things are simple to build as one.

An auth plugin, for example, would be 1) a module with the logic needed, 2) a CLI plugin with a generator for the app integration. Makes sense?

[asavin]

@charypar yep, makes total sense