Different Flavors of Expo
closed
c
clark tank
So far me and 215 people have asked for adding react-native-firebase to expo. We have been the most trending FR on canny until last week!
I think I know why we haven't heard back from Expo and here is my solution to your concern.
------------------------------------------------------------
Why:
Currently, the highest voted feature request is for "Background location tracking" with 380 votes.
Subtracting 216 from 380 leaves us with 164 people who are either neutral or against adding Firebase support.
That is understandable because nobody wants extra code bundled in their app.
------------------------------------------------------------
Solution:
Making different flavors of Expo (like Linux) is going to solve this problem.
I think, flavors should focus on three main functionality:
a) Navigation: React-Native-Navigation or React-Navigation
b) Backend: React-Native-Firebase or Appsync
c) Localization: React-Native-Maps or Mapbox-GL
------------------------------------------------------------
In my opinion, Expo should see itself as a very experienced react-native developer who happens to be a framework!
In React-Native ecosystem, there are many out dated libraries that sometimes don't work well with other libraries.
Only experienced developers know about that.
------------------------------------------------------------
Based on my observation, Facebook has decided to rely on the community. So somebody has to bring it all under one umbrella, and that could be Expo!
But in order for this to work, Expo has to set some high level guidelines, so developers follow them and build native libraries that work well with Expo's flavors!
------------------------------------------------------------
I must say that I really appreciate the hard work done by the folks at Expo. You might have already thought about this. I am just stating my opinion here and that's all!
Evan Bacon
closed
This covers too many features, it is too hard to tie a singular feature to this canny request. There is a solution to this in the works.
Harshul Sharma
There will be no need of having separate packages of expo if during construction of native app, expo could remove unnecessary native app code that automatically gets bundled.
Alexandr Priezzhev
I don't think the proposed approach will give any positive results, because you never know, what combination of modules every other developer needs. For example, currently I work on the app, which use all three mentioned main functionalities (nav, firebase, maps). However I have other apps, which use non of the above. So the approach with "official plugins" seems much more promising for me, it will both allow to use wider range of native modules (like firebase) and to reduce the app size.
c
clark tank
Alexandr Priezzhev: Thanks for reading the proposal. Before I dive into explanation of why this proposal is a well thought out approach, I'd like to make a quick point, on the case where you don't need neither of the functionalities.
Currently, you still have to download the Expo that comes with a lot of functionalities or modules, so it wouldn't make it worse than before! The solution to that case is to have a Vanilla Expo that only come with Expo's home-made apis.
c
clark tank
I have carefully, looked at all the canny FRs and choose the ones that are popular and behave in a binary fashion.
For example, 86 people have voted for the support of Mapbox-GL and if you are going to use Mapbox-GL you are not going to use react-native-maps. Therefore I made a category (c) for it.
Same for React-Native-Navigation, it has 96 votes and it behaves in a binary fashion, meaning you are either going to use React-Native-Navigation or React-Navigation, therefore category (a).
Same explanation goes to adding React-native-firebase which is the most popular of the two with 218 votes and it behaves in a binary fashion. You are either going to use it or use Amazon's Appsync or something else.
3 categories give 6 different combinations. and one Vanilla Expo to keep everyone happy.
In order for Expo to be really popular, it has to support all these high voted feature requests. Making different flavors of Expo will satisfy the demand, reduce the app size, therefore positive results!
Alexandr Priezzhev
clark tank:
Of course, keeping Expo in it's current state will not make it worse. But the problem is that it is hardly usable for many usecases. So you have to detach it and add missing pieces (like Firebase). Lots of people vote to add these pieces into Expo, however the problem is that it becomes not just larger, but less stable. So it should be modularized in some way. There are a few choices to to that:
- a few flavors (your proposal) - will not really solve nor size, nor stability issues
- reduced to minimum Expo "core" + a set of official packages, so you will be able to choose what you need for your app. This should solve both issues
- Same as 2, but with possibility to add community packages (the approach for the implementation is unclear)
Having just 3 categories you will get 8 (not 6) combinations - this is in the case when the flavor contains an item from every cat. If the flavor will contain just two, number of combinations will grow again. If you suddenly add one more category, the number of combinations will become 16 (having same restriction - an item from every cat), etc.
So the complexity of maintaining the flavors approach grows much faster in comparison with 2. and 3., which grow linearly with the growth of number of packages (with those 6 packages you have mentioned there will be 8 flavors aganst just 6 modules, if you add one more category, there will be 16 flavors against 8 packages, etc.)
c
clark tank
Alexandr Priezzhev: I think that I have confused you, but 3 categories give 6 unique combinations.
3! = 3x2x1 = 6
C1) React-native-navigation / React-Native-Firebase / React-Native-Maps
C2) React-Navigation / Appsync / Mapbox-GL
C3) React-Native-Navigation / React-Native-Firebase / Mapbox-GL
C4) React-Navigation / Appsync / React-Native-Maps
C5) React-Navigation / React-Native-Firebase / Mapbox-GL
C6) React-Native-Navigation / Appsync / React-Native-Maps
Alexandr Priezzhev
clark tank:
Number of combinations = 2^3 = 8
a) Navigation: (A1) React-Native-Navigation or (A2) React-Navigation
b) Backend: (B1) React-Native-Firebase or (B2) Appsync
c) Localization: (C1) React-Native-Maps or (C2) Mapbox-GL
- A1, B1, C1
- A1, B1, C2
- A1, B2, C1
- A1, B2, C2
- A2, B1, C1
- A2, B1, C2
- A2, B2, C1
- A2, B2, C2