Idea: Rewrite project as a "patch" on top of create-react-native-app/react-native init

[FruitieX]

Ideas welcome!

I'm thinking about rewriting this project as a "patch" you apply on top of a fresh create-react-native-app and/or react-native init project. This would bring the following advantages:

• Eases the maintenance burden by making react-native version upgrades no longer be our responsibility
• Potentially easier for newcomers by allowing easy Expo use (via create-react-native-app)

Downsides:

• No more git-based upgrade path for users (although I'm wondering whether there was any easy way to do a template upgrade in a mature project anyways without a lot of conflicts)

I'm not really sure about the details yet, trying to come up with a prototype ASAP.

[FruitieX]

Proof of concept in crna branch: https://github.com/futurice/pepperoni-app-kit/tree/crna

Currently it's just a create-react-native-app project with a rewritten version of Pepperoni thrown on top of it (missing plenty of features), but the plan is to write a tool which patches this on top of an existing CRNA / react-native init project.

[dominictracey]

Interesting stuff. I've enjoyed working with this over the last few weeks but have certainly noticed that it would be nigh impossible to keep a forked repo in sync with the origin.

[HZSamir]

That would indeed be interesting. I for one am in support of this idea.

[FruitieX]

Here's some progress so far: https://goo.gl/photos/47AfGWG3MxoKUQPH8

Each tab is the result of running a plop generator.

[dominictracey]

Looks great! So redux-persist for snapshotting to/from AsyncStorage? Do you have an opinion on redux-loop/saga/redux-effects integration? I see that the redux-loop 2.x used in the current master has been deprecated with a 3.0 version that replaces Effects with Cmd.

[FruitieX]

Yeah, figured using redux-persist makes sense instead of a home-grown solution like what we have in master. redux-persist also has extra features through addons such as blacklisting/whitelisting, migrations, filtering, expiring properties etc.

[FruitieX]

As for redux-loop, yeah definitely either upgrade to 3.0 or leave it out / use something else. I haven't made any decisions here yet. One possibility is leveraging the generator framework and letting the user choose which async Redux library they would like to use.

From my experience, the most common async operation is API requests. In my opinion we should pick a solution where API requests are as easy as possible to make and track the progress of (+error handling). The solution could be a similar service as we have in utils/api.js.

In the ideal case, someone who hasn't ever heard of Redux should be able to make API requests and fetch the results/error/status in their components, just based on some usage examples we provide and without a lot of boilerplate. :)

Again, ideas are welcome! Nothing has been decided on yet.

[dominictracey]

I like the redux-persist inclusion. I can see issues arising already from using the simplistic solution in the master branch and redux-persist offers ways arounds this (in particular, the ability to control state serialization at the reducer granularity).

The async redux challenge is a bit stickier - I guess the question is who is the target audience for the app kit? Are you providing an opinionated solution or a more robust/flexible framework that allows users to craft a solution. I was new to react-native (but not react/redux) when I created an app from Pepperoni a month ago and very much appreciated the opinions expressed therein. I suppose I was under the impression this used by Futurice to kick start mobile development engagements.

While I see the value of solving the rest api asyncronous problem, I was interested by redux-loop's ability to "schedule" actions from within reducers. It sort of flirts with the redux anti-pattern of reducer side effects but I liked it as a inter-reducer communication paradigm that supported a clear separation of concerns in the architecture. One thing I never got around to sorting out with it was the logging of Effects-spawned actions to the console and having them actually dispatched in jest. You can confirm they are created by the reducer, but they aren't dispatched. This gets back to the anti-pattern I suppose - it is good to be able to test the direct output of the reducer, but validating the complete set of state changes when the Effects were actually processed was a challenge.

All that to say that I like the idea of a shrink wrap solution for REST calls, but would like to see an action scheduling capability like redux-saga, redux-loop or redux-effects included.

[dominictracey]

On the high level CRNA decision, master now includes react-native-vector-icons, which has to be react-native linked. Since this is a trigger for CRNA ejection, I'm assuming it won't be part of this new model?

[FruitieX]

@dominictracey react-native-vector-icons are part of Expo, so they will continue to work. IIRC even importing from react-native-vector-icons using the same library name as before should work (even though Expo also exposes them through @expo/vector-icons)

https://docs.expo.io/versions/latest/guides/icons.html

[dominictracey]

Ah - I didn't really get the dependency/integration on Expo in CRNA. Now the I've pulled your branch and messed around with it, it makes a lot more sense. I just cloned the branch, yarn install and npm run android. How does the "patch"ing work? Are you thinking it would look like:

$ npm install -g create-react-native-app
$ create-react-native-app my-app
$ npm install -g pepperoni-patcher
$ pepperoni-patcher my-app
$ cd my-app/
$ npm start

It doesn't seem like CRNA is versioned, but it just tracks the underlying dependencies.

[FruitieX]

Yeah, something like that flow, although as a shorter & easier alternative I would provide a shortcut in the pepperoni CLI that takes care of creating a project for you from scratch using CRNA / react-native init.

[HZSamir]

I am liking this very much @FruitieX Please do keep us informed!

[HZSamir]

Is this still a thing?

[FruitieX]

I'm currently working on a client project based off of the CRNA branch and it's working fine. The project ends soon-ish (before end of year), and I will cherry pick anything useful and generic enough from there into the CRNA branch. Maybe after that we can start thinking about releasing this as a separate starter kit?

[FruitieX]

To add to the previous comment, we still need to fix/decide on a few things to make this branch useful for others:

• A nice way to patch this over a create-react-native-app project. Do we maintain a git repo with the latest version as before or do we create a tool that copies the template over a fresh project? Or something more exotic?

• Documentation. There's currently absolutely none. :(

• Write tests. Same story here at the moment. :(

• Rewrite in TypeScript?

• Provide some examples of making API requests. This includes choosing if we want to either:

  • Do API requests ourselves and include an async redux library? Write example reducer, actions, action creators, ...
  • Use something like redux-api to handle creating the redux boilerplate (although the library's documentation is not the best)
  • GraphQL?

• Make the back button handler in src/containers/navigator/Navigator.js more generic. It only supports a TabNavigator as root navigator, which might not be what you want in larger projects.

• Immutability library? Something like https://github.com/leoasis/redux-immutable-state-invariant instead of Immutable.js?

[HZSamir]

I have no strong opinions about all of the above except TypeScript Please don't

[aaronfranke]

What's the status of this? Has there been any work on it? Is this still a potential goal?

Can Pepperoni work with Expo?