Ignite: Ignite 2.0 EPIC Storyboard

Created on 23 Oct 2016  路  17Comments  路  Source: infinitered/ignite

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-screens
  • ignite use ava
  • ignite add I18n
  • ignite use redux
  • ignite use sagas
  • ignite use apisauce
  • ignite add reactotron
  • ignite add redux-logger

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

  • Programmatically editing .xcodeproj sucks. react-native upgrade becomes useless when you have enough native configurations
  • Configuration management (dev, staging, prod) is not obvious to set up, should be included and documented
  • Targeting newbies is painful, because if they run into problems they have no idea how to fix them. Piling on ready features on newbies is also dangerous, because if they don't understand the why, they won't understand how to effectively use things. Documentation that explains why certain decisions were made is a must if targeting React/Native beginners!

What npm modules should be included?

My opinions on these:

  • Library-wise, support everything that Exponent supports.
  • Make 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)
  • Make AVA optional (fall back to Jest which comes out of the box now)
  • Make apisauce/reduxsauce optional
  • Add optional immutable.js
  • Add optional CodePush
  • Add optional Fastlane and CI configuration files (e.g. bitrise or travis)

Generator interface

  • CLI or a locally-served web-based configuration UI would be good
  • Error messages must be first class - what failed, why, and how to work around manually
  • Must work on Windows
  • Some presets would be good (kitchen sink with example code screens for those who want to understand how things work, and a plain, minimum starting point for those who want to build their own stack)

All 17 comments

Looks 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:

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

  • Programmatically editing .xcodeproj sucks. react-native upgrade becomes useless when you have enough native configurations
  • Configuration management (dev, staging, prod) is not obvious to set up, should be included and documented
  • Targeting newbies is painful, because if they run into problems they have no idea how to fix them. Piling on ready features on newbies is also dangerous, because if they don't understand the why, they won't understand how to effectively use things. Documentation that explains why certain decisions were made is a must if targeting React/Native beginners!

What npm modules should be included?

My opinions on these:

  • Library-wise, support everything that Exponent supports.
  • Make 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)
  • Make AVA optional (fall back to Jest which comes out of the box now)
  • Make apisauce/reduxsauce optional
  • Add optional immutable.js
  • Add optional CodePush
  • Add optional Fastlane and CI configuration files (e.g. bitrise or travis)

Generator interface

  • CLI or a locally-served web-based configuration UI would be good
  • Error messages must be first class - what failed, why, and how to work around manually
  • Must work on Windows
  • Some presets would be good (kitchen sink with example code screens for those who want to understand how things work, and a plain, minimum starting point for those who want to build their own stack)

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

besingamkb picture besingamkb  路  3Comments

GantMan picture GantMan  路  3Comments

ron-liu picture ron-liu  路  4Comments

orozcojair picture orozcojair  路  3Comments

whalemare picture whalemare  路  3Comments