This is the example storyboard of creating a new project in Ignite 2.0
It's rough work: Feedback welcome @ryanlntn @kevinvangelder @derekgreenberg @jamonholmgren @skellock @fvonhoven
$ ignite new MyAwesomeProject
Welcome to Ignite - The Unfair Headstart Generator
By default all Ignite apps come with Vector Icons, Config, and Animatable.
Would you like to go through our composer? (y/n)
y
The following questions will help us choose your additional goodies.
Would you like the Ignite Development Screens? (y/n)
y
Testing? (use arrow keys)
1. AVA tests with nyc code coverage
2. JEST tests
3. No tests, just madness
1
Would you like I18n support? (y/n)
y
State management? (use arrow keys)
1. Redux
2. MobX (not yet supported, so don't select this)
3. None
1
Redux flow control? (use arrow keys)
1. Sagas
2. Thunk + Sagas (not yet)
3. Async/Await (not yet)
4. None
1
API? (use arrow keys)
1. APISauce
2. Fetch (not yet)
3. None
1
Debugging? (select all that apply)
[ ] Reactotron
[ ] Redux Logger
Enforce Standard JS on Commit? (y/n)
y
This flow feels natural for me, though I might be blazing past some fundamental questions, and focussing too deeply on others, but let's see.
The above can be added after the fact with the following: I've chosen-kebab-case for Ryan
ignite add dev-screensignite use avaignite add I18nignite use reduxignite use sagas ignite use apisauceignite add reactotronignite add redux-loggerLooks really good @gantman. Also allow skipping all or adding all standards via flags.
$ Ignite new MyAwesomeProject --skip-all
$ Ignite new MyAwesomeProject --defaults
(Or something like that)
LGTM!
@GantMan Perhaps an option to choose Navigation? (Native or RNRF)
So far, looks great. Maybe instead of offering options that are not supported (such as 'MobX (not yet supported, so don't select this)'), leave them out. Maybe add a line break + some promo copy to the storyboard prompts, such as 'Support for MobX will be added in a future release'
I wondered about:
ignite add login
Which might generate a login scaffold for an api back end.
Another item to add to the storyboard:
Create directory? (use arrow keys)
1. <name of app as entered previously>
2. <name of app in kebab case>
3. other
4. none
I would like this option added to the storyboard because I'm working in a git directory with a kebab-case name and don't want a directory generated as part of the app. Another scenario is that you want the app name to be used throughout the generated files, but you want everything generated in a directory with a different name, which is where the 'other' option comes in. If the user selects 'other', the storyboard then spits out a prompt:
Directory Name:
If the the user selects 'none', no outer directory is generated.
@derekgreenberg - I feel this might be a corner case. Perhaps a flag passed to the initial ignite command?
A flag passed to the initial ignite command would be awesome!
blueprints can be done like they are done here: https://github.com/SpencerCDixon/redux-cli
Hey guys, just chatted with @GantMan a few hours ago about what you're working on. Cool stuff! Turns out I had already starred this project and I don't even do react-native haha.
I've been wanting to extract the blueprint generation code from redux-cli for a while now and de-brand it from redux if you will. There is really nothing specific about redux in the project other than some default generators for common reduxy/react type things you'd want generated.
I'll dig into your guys code a bit so I can have better context but if someone wants to fill me in (or point to github issues) on what the goals/dreams are for the generator based functionality, or has any questions regarding generators, I'd be happy to help out.
Welcome @SpencerCDixon! Here's a good place to read: https://github.com/infinitered/ignite/wiki/Intro-to-Contributing-to-Ignite
We're excited to hear/see your thoughts as we figure out a way to make blueprint functionality possible.
@GantMan asked me to write up thoughts about Ignite 2.0. Here's a dump of that conversation:
Generators are a cool idea, definitely something I wanted to do in Pepperoni but never got around to doing. Main pain we wanted to solve with them was that too-unopinionated boilerplates are useless, but more opinionated you get, more people complain about not agreeing with some of them :) Letting people pick their opinions 脿 la carte seemed like the best tradeoff.
For generators to be truly useful, they should extend beyond just bootstrapping a new project: Most people don't necessarily know what they want out of the gate, and they will want to add things to existing projects. To be able to do that, you need to either write a pretty advanced AST-based generator that can identify the right places in the code to inject changes, or to separate the framework part from the userland code and allow modifications to the framework part, 脿 la create-react-app. Have you considered making Ignite more like CRA in that regard?
react-native upgrade becomes useless when you have enough native configurationsMy opinions on these:
redux-saga optional (if users want to opt out of saga, include thunk/nothing and let them pick their own - if they know enough to avoid Saga, they'll know what they want instead)This has been started in PR #498
Feedback on what's been started is welcome. This is the first E2E solution. I see it evolving quite a bit once we start using this in the field.
Woah! I didn't know it was so much like our idea of ReazyFramework.io 馃槻
Woah! I didn't know it was so much like our idea of ReazyFramework.io 馃槻
Didn't we talked with you late last year about Ignite 2 and you wanted to build a plugin? :rofl:
I think @jevakallio was building GetPepperoni at the same as we were building Ignite 1.0. The idea isn't unique. We all share this problem as soon as you start firing up project number 2. Snowflake was the first, and now there's about 30 boilerplates. Even React Native is doing it now.
But as @jevakallio points out: mechanics & opinions need to be separated for this to evolve.
Flexibility is what Ignite 2.0 has been about. There are multiple right ways to build an app. Redux is right. MobX is right. Apollo is right. Exponent is right. Boilerplate libs tend to stop at 1 answer. I know we did.
But, we learned that it's better to be the batmobile and let the user be batman.
This is where we're heading. Middleware. With optional sugar on top.
You should jump into our #ignite Slack channel at http://community.infinite.red. Even if our codebases don't unite, we can still shoot the shit & talk about this together!
鉂わ笍
@skellock First of all thanks a lot for explaining the problem with the community so well.
And I didn't know we were talking about Ignite 2.0 back then. Better late than never though. Gant gave us a demo in the meet up and it's AMAZING!
And also, we believe in the same idea of "mechanics & opinions need to be separated".
I have joined the Slack community. We can definitely talk and collaborate wherever possible. 馃憤
Closing as we're wrapping this up. Cheers all!
Most helpful comment
@GantMan asked me to write up thoughts about Ignite 2.0. Here's a dump of that conversation:
First thoughts
Generators are a cool idea, definitely something I wanted to do in Pepperoni but never got around to doing. Main pain we wanted to solve with them was that too-unopinionated boilerplates are useless, but more opinionated you get, more people complain about not agreeing with some of them :) Letting people pick their opinions 脿 la carte seemed like the best tradeoff.
For generators to be truly useful, they should extend beyond just bootstrapping a new project: Most people don't necessarily know what they want out of the gate, and they will want to add things to existing projects. To be able to do that, you need to either write a pretty advanced AST-based generator that can identify the right places in the code to inject changes, or to separate the framework part from the userland code and allow modifications to the framework part, 脿 la
create-react-app. Have you considered making Ignite more like CRA in that regard?Pain points
react-native upgradebecomes useless when you have enough native configurationsWhat npm modules should be included?
My opinions on these:
redux-sagaoptional (if users want to opt out of saga, include thunk/nothing and let them pick their own - if they know enough to avoid Saga, they'll know what they want instead)Generator interface