Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generic question on building a library on top of material bread? #313

Closed
gcloeval opened this issue Oct 11, 2019 · 4 comments
Closed

generic question on building a library on top of material bread? #313

gcloeval opened this issue Oct 11, 2019 · 4 comments

Comments

@gcloeval
Copy link

Hi,
First of all thank you for this amazing library.
We are doing some quick prototyping of native kits - between nativebase, native elements, kitten etc. We gave each kit one day to see how much we can produce, and native version of material bread is a clear winner - excellent documentation and great examples. Real cudos for great work!

This is now forcing us to re-evaluate if we should also consider it for web. We have originally decided to go with standard material-ui.com + some extra 3rd party libs.

To clarify, we are building an internaly library, not an app, to be given to different departments.

So if we build a set of components on top of material-bread - for ex. "material-bread-search", will it be possible to publish/produce just a standard web-only library version to give to another department that already has a web-app and doesnt care anything about native or native web (i.e. they already have CRA running and building and publishing their app and just want to do for ex. yarn add 'material-bread-search' - or will they also have to 'buy-in' fully to switching to react native for web under the hood? They already use material-ui.com, so of course we would have to take care of theming the material bread to match what they have.

Similary, we can give just the library to native team who doesnt care anything about the web (its a completelly different app, but needs the same search)

And some 3rd department that needs both we can fully unify i.e. via your https://www.reactnativeinfinity.com/.

Even if not possible right now but yes in theory, please let us know any insights you might have.

Thanks again

@codypearce
Copy link
Owner

codypearce commented Oct 11, 2019

We gave each kit one day to see how much we can produce, and native version of material bread is a clear winner - excellent documentation and great examples. Real cudos for great work!

That's an awesome experiment, glad you found Material Bread so useful!

So if we build a set of components on top of material-bread - for ex. "material-bread-search", will it be possible to publish/produce just a standard web-only library version to give to another department that already has a web-app and doesnt care anything about native or native web (i.e. they already have CRA running and building and publishing their app and just want to do for ex. yarn add 'material-bread-search' - or will they also have to 'buy-in' fully to switching to react native for web under the hood? They already use material-ui.com, so of course we would have to take care of theming the material bread to match what they have.

RNW, in a general sense, is just translating React Native to React DOM, so you can integrate React Native Web components and regular React components in the same web app. Both https://material-bread.org/ and https://www.reactnativeinfinity.com/ use some CSS, HTML markup, other web specific libraries along side Material Bread components and React Native components. But ultimately I think it depends on how much code sharing you want and how much you're willing to configure your web app.

Web depends on RN and RNW
If you're ok setting up RN and RNW for your web app, then your component can share as much as possible between both platforms and integrate with your current React components.

Web depends on React Native but uses many web apis
If you're ok with the web app depending on React Native, then you could publish one library material-bread-search and use Platform-specific extensions (index.web.js and index.native.js) to maintain the two parallel components, but you couldn't rely on React Native functionality for your .web.js component.

Web doesn't depend on React Native
If you want the web app to truly not know anything about React Native or React Native Web, then I think you'd have to maintain two libraries for your search component material-bread-search-web and material-bread-search-native, where the web version is a basic react component with HTML markup.

Similary, we can give just the library to native team who doesnt care anything about the web (its a completelly different app, but needs the same search)

I think this is a perfect use case for sharing the same component across both platforms, if the search is the same on both (with minor differences), then I'd just create one library material-bread-search with one component and set up RNW in the web app along side regular components or even material-ui.com components.

@gcloeval
Copy link
Author

Hi thanks for the clarification. Yes, I think we will have to go with a separate web version. There is like 10-15 existing CRA apps, and looking at the setup, they would also have to eject in order to modify those babel loader rules, correct?

@codypearce
Copy link
Owner

There are a few packages that allow custom webpack rules for CRA apps necolas/react-native-web#1192, for example https://github.com/timarney/react-app-rewired, but they're not officially supported by the React team.

@gcloeval
Copy link
Author

Yeah, the teams were in that situation before where everbody was using their own build versions, some CRAs, some custom, some rewired. It was causing too many inconsistencies when adding shared libraries "cross-apps" - exactly like just right now with the enterprise search, hence decision was made to standardize on CRA and material-ui.
It will be too difficult to fight the battle, I can forsee 20+ urgent "architectural meetings" if we are to propose now any such tweaks.
Since we already decided (and budgeted) to go ahead with 2 libs - web and native. It was just during native kits evaluations we were so impressed with material bread that we wanted to reconsider. We will just use it for native for now and if somebody needs something like electron, guess what, we are already good to go :)
I will close the issue then, keep up the great work man!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants