I'm learning React. My goal is to create a few components that render cross-platform. Specifically, I'd to create components with the option to a) render in the browser b) render on the server c) render natively on Windows and d) render natively in iOS. Based on my limited understanding, it seems like each of these cases are possible. I'm trying to understand the simplest way to do this though. It almost seems like each scenario requires a different approach, which almost results in four different components. This seems like a misunderstanding on my part though.
If I wanted to render a button in the four scenarios above, what is the simplest approach? I figured a tutorial showing this would exist, but I haven't found one.
Thank you
First of all, try to use packages that support all of your environments. But if you need separate implementation then you should do it like this
Button example you mentioned:
create a button folder
create a Button.js or index.js file
create Button.[enviroment].js files you need and export only one Button component in the root Button.js file. like this:
-- /components
-- /button
-- `index.js`
-- `Button.web.js`
-- `Button.android.js`
-- `Button.windows.js`
// Button.web.js
export const Button = ({title}) => {
// web specific implementation
}
// Button.windows.js
export const Button = ({title}) => {
// windows specific implementation
}
// index.js
export {Button} from './Button'
What I know from React is that React components are different from React Native ones. you can't have a single component to be used both in React and React Native and you should create separate projects for each one. but in React Native you code once and you can run it on both android and IOS and as they introduced recently no windows and mac too (1).
So to wrap things up, you should separate your web application from your native applications (which can be android, IOS, windows, and mac) but since React and React Native are not that different from each other, it won't be as hard as starting a new project.
Your react native code works in both Android and Ios(unless you use some libraries which are platform specific) . To run your react native code in web, use react-native-web. For windows and macOS use this.
Best part with all this is, you write the code only once but run it everywhere.
Interesting - I thought I'd post some related thoughts based on my own efforts on unified UIs. It may not answer your question directly, but I hope it is of interest.
REACT AND APPROACH
I would argue that you should use the right tool for the job. React is a great choice for Single Page Apps, and also surprisingly good for Desktop Apps:
An SPA will run in all desktop and mobile browsers on any OS
A desktop app will run on Windows, MacOS and Linux
MOBILE
I work a lot with security tech, which requires up to date native support. In these cases Swift and Kotlin shine, and technologies such as React Native become hard work, because you are always going through extra layers, with many annoyances.
CODE EXAMPLES
My ongoing struggles with cross platform UI technologies are here, and they include a React SPA and React desktop app, both of which deal with difficult OpenID Connect security flows.
UI code is the same in all cases, including mobile, but I avoid React for mobile apps. Code sharing would be more effort than it is worth. Also, in a real company, mobile and web is often developed by different teams, who should be able to choose their own tech.
SUMMARY
The thing that should be shared is design patterns, not technology or code. Design patterns will scale over time, whereas code sharing will not.
I would like to be able to render user interfaces for cross-platform audio plug-ins (VST, audiounit) on desktop machines using HTML UI, in a similar approach to this project https://github.com/russellmcc/audiounitjs
Unfortunately native web views are significantly different [and particularly limited on windows].
I'm investigating whether I can use libchromiumcontent from the electron project to do this, but I can't find a basic tutorial that looks appropriate e.g. a basic c++ app rendering a UI using HTML. I'm not even sure if that's gonna be possible. Perhaps I have to wait for mozilla's servo? because I am developing audio plug-ins, the plug-in host controls the main application loop. Does this means I cannot use libchromiumcontent?
thanks
So my question is pretty self explanatory. Does it make sense to use Vue.js and React.js together on a same project ?
No. Both Vue.js and React are for the same purpose - building UI components.
The only situation that it might make sense is that if you are doing a migration. From Vue.js to React or from React to Vue.js.
But I think in most scenarios it doesn't worth to do this kind of migration. Both Vue.js and React are really great. So my conclusion is, no, it doesn't make sense.
Both Vue and Reactjs are javascript Frameworks that are in themselves self sufficient. Also since both do the same job it makes sense to use either one of them.
If you use both Vue and React together it will make it more and more difficult for you to share states and data between parts written with Vue and Parts written with React.
What you would have to do is to keep them as independent modules.
Also both Vue and ReactJs have different APIs so it makes it difficult for a developer to code it out too. This will lead to bad patterns and hacks developing in your code which will later lead to issues such as maintainability and feature extension.
If you have control over your entire code, its better to just evaluate what better suits your purpose and then choose that framework for development of the entire app.
P.S. Certains exceptions to using both of them together will include a migration from framework to another in progress or your app having various modules in your App each of which independent from one another and included as plugins in the main code.
You can use the two together but you will have to carefully consider the architecture. You might have to consider something like the Microfrontend architecture but remember this comes at the cost of a lot of complexity and is not suited for all use cases.
Good intro to Micro Frontends
So we've recently picked up React in our company as the front-end technology to build our huge business web application. By saying recently, I mean we don't have any previous experience with React (we have a huge background of AngularJS), and by saying huge application, I mean it's really huge and very dynamic with lots and lots of different pieces and functionality.
Because we will have a lot of huge components that all play a very important role and have complex logic inside them, and because we want them to be easily pluggable and reusable, we want them to be as isolated as possible from the outside world and other parts of our application, because otherwise because of their size and complex functionality it would be pretty much impossible to develop and maintain them. That's the reason why we have decided NOT to use Redux, at least in the beginning, while we are developing just the separate components themselves, because it compromises component isolation and makes the whole application data flow logic impossible to understand when there are so many complex components. Although I believe our choice could be wrong, because as I've already mentioned, we have no experience with React.
As I've already mentioned, the application is very dynamic. By that I mean that components are actually rendered by data. We use various configuration provider classes that interacts with our API endpoints to get the pieces of our application's configuration, like configurations of navigation, pages, various forms, lists, etc., and then try to render components that are read from that configuration.
The problem is, after a couple of weeks struggling to get the momentum with React and discover the right patterns and common solutions to our problems, we've been talking in our crew, that maybe React is not the right technology for us, as it's a UI library, not event a framework, and it doesn't help us a lot, but just adds its rendering rules that we have to break at times to achieve the dynamics and component independence we want.
Considering the component isolation and data flow management, I personally have heard that there is a language for front-end development Elm that has pretty robust data flow architecture where each component has its own model that is separate from others, but I don't know whether it's worth a try, as it may fall behind our big requirements pretty soon too.
The reason I'm writing this question here is that I hope to get an insight from people that have a solid background on working with huge front-end applications. I'd like to know whether it's possible to develop such an application with React, whether React is suitable for such complexity and dynamics, whether we really need Redux or something else, what path, practices, ideologies should we follow. If you understood my question correctly, it's more the architecture side that we are struggling with, than the technological. Maybe we are just walking the path that leads to more and more struggle and complexity but not towards production.
There is absolutely no question that React/Redux can (and is widely) used to develop the kind of applications that you describe. Nothing in your description makes what you are building so unique that it excludes React as a platform for building it. We are actively working with a large enterprise customer who is building their entire front end - with 100 + SPA (Single page applications) in React. This is a team of over 100 developers over a 2-3 year project.
The way we structured this has been crucial -
First, you want to choose a UI component library. A few examples below :
MaterialUI - https://github.com/callemall/material-ui
React Strap - https://github.com/reactstrap/reactstrap
React Bootstrap -https://github.com/react-bootstrap/react-bootstrap
Khan Academy React Components https://github.com/Khan/react-components
https://github.com/elementalui/elemental
We basically took one of these and built a component library off of them, because our components are very custom styled.
Second, we created a modular architecture, where each module (SPA) is an npm package with a main container component and redux store.
Finally, we have a central server package, where each of the modules is registered. The server package is responsible for authentication, authorization, logging, routing, etc.
The essence of this answer is not to advise on how to structure a large React application, but to let you know that React can be (and is being) used to develop applications similar to what you are describing.
I'm at the similar situation right now. I have a background in large desktop applications (ERP, LOB - WinForms, WPF) - 1000+ modules, very dynamic (more than 70% of the UI was generated by input data/configuration), adding new functionality was just about extending some configuration (without touching source code).
I'm deeply investigating current web technologies and I'm more and more convinced that React is not a good fit for that. React really shines in small/middle size applications where you (and other team members) develop every page/component 'manually' (not dynamically generated) and you want to have one global state. But it doesn't help you with building large scale application out of the box - it is only UI library (so no support for modules, routing, forms, binding, http requests, static typing (typescript), etc.) and to my surprise, there is no support for style shadowing/encapsulation (you have to integrate, for example, CSS Modules, by your own). And at the end, you have to constantly bother with libraries versioning (to make them always work together is truly time and energy consuming).
I have a great experience with Angular 2/4+ and I think, for now, it is the best technology for that kind of the applications (if you know WPF, it is very similar). It is a full framework, which is prepared to the scaling out of the box. You can split your app into independent modules (specifying which components will be visible to the outside world), every component has public api (statically typed, inputs/outputs) and encapsulated css styles (there is no interference between others).
For the global state (logged in user, global configuration, etc.), you can still use library ngrx/store (which implements Redux pattern and comes with extra nice things, like 'effects' and integrates really well into Angular ecosystem).
I tried to do in Angular really crazy stuff (dynamically generating the whole application from backend configuration) and everything worked perfectly, as expected.
You nailed the issue in your question- react is a view library, not an application framework. The real question is whether React+Redux(or other state management system) is appropriate for a large LOB app.
I will share some insights from our team’s experience in this realm. Large LOB apps have been developed using the MVC/MVP/MVVM design patterns for decades. These are tried and true patterns that ship software. Couple that with dependency injection and you have a modularized, testable, maintainable application. AngularJS (2.0+) is founded on these principles and leverages them deeply. For this reason we use AngularJS for all of our enterprise line of business apps.
React on the other hand is a lightweight, spritely view render that is awesome for smaller applications and client facing pieces (for example taking a dynamic survey or a simple dashboard). We often turn to React and VueJS here because the full AngularJS stack is way overkill and too heavy.
Getting started writing more complex apps in React can really be a struggle, I know exactly how it feels!
As you say, React is a UI lib and not an event framework. That's why you typically need a library to handle events, for example Redux. You clearly state that you decided not to use Redux (you even used capital letters for not :) ). I would take a step back if I were you and reconsider that decision. You say the reason for not using Redux is that your cannot keep your components easily pluggable and reusable when using Redux. I would argue that is not true. Redux is totally decoupled from your React components. Redux only handles receiving events, and managing state. From the React components point of view, it just receives data in props and sends events by calling regular functions. It's possible to still unit-tests, reuse, etc.
I would suggest you take another look at Redux with this in consideration. Happy to help if you have more questions!
React , Redux will make things easier because When it comes to
complex applications you can create Well structured data object. then you can manage the Complete UI through React and its
Materials ... There are some reasons Why this is right choice
State Management ,
Tree Structure data handling,
Reduce the code,
You will be knowing where the changes made (Actions, Reducers)
Your Component will only taking care of UI things
The things that you have to do is Structuring your data
Completely understand your feelings when you start with React and Redux. We were in the same situation when we started with React in our company. At first React has different approach than other frameworks. Yes of course it's not framework, it's just library. You have to start thinking in React way and that is: React components just render state (It's like you render scene on your graphic card at first you have to prepare scene then you are able render), all what component can do is dispatch actions, or better call just action creators.
You need some smart way how to store state in that point I will suggest use Redux.
We also use TypeScript with combination React, Redux. you have to write more code than pure JS but static type control is priceless when you work on large project.
Separating components logic is native approach of react ... you have to separate logic write "Dummy components" and then reuse this with connect. Or passing values as props.
We are using Thunk middleware as action creators it's good because connected component will call just method and logic is in action creators. You have access there to whole state of app then you can fetch something and base on result you can dispatch different actions.
What I like on react/ redux is how to implement async calls etc. First design component to map all states
1) like I have no data
2) data loading
3) loading done
4) loading error
For that you need only one semaphore in you state and a few checks in render method. Then one action creator that will load data and base on progress dispatch action that describing progress.
What is also cool that in react/redux app you have single data flow it's good when new dev jump into project.
For UI we are using Material UI, yes this framework has some problems but nothing what you will not able to deal with.
We are using also Router for navigating in app.
In the beginning I will avoid server side rendering because it will much easier for you start just with client side rendering and with initial state.
When we start for us was useful this template where everything works in one project JavaScriptServices
Then off course great Abramov tutorials.
For design components very useful Storybook
We can write why use or not React for long time ... but What I can say ... for us it was good choice, with some pain in begging but now we have good payback.
We started a large scale business application using Reactjs as frontend technology.
We have over 30 people in the team and we have over 15 modules in our product.
My approach is to the project is developing a common react project that handles only the Authentication, authorization and routing of the application and all other components developed as separate npm react libraries.
To develop the libraries I used https://www.npmjs.com/package/create-react-hook
This library generates the template with an example app which can use to test our library.
Following is the structure of the project
--Library 1 ( Developed using create-react-hook )
--Library 2 ( Developed using create-react-hook )
...
--Library n
--Common Container App (Developed using create react app and have used all above libraries using npm install)
The main advantage of this approach is developers can focus only on their npm packages and they can develop and test relevant component(s) separately.
The deployment also becomes very easy because we can just update npm package of tested version and rebuild the container app and do the deployment without affecting any other part of the application.
We are using this for several months and running the project with a large team without any issue. I think this may be helpful to anyone else too.
So this is just to share my experience working on an enterprise react application that is in production for years in several banks. yes, you heard me right. Now you can imagine how huge the application will be if it's related to fintech (I know it's not always the case). we have huge modules (70+) with a complex logic that pretty much handles a lot of the work that a bank needs. Modules are both isolated and re-useable. I am going to give an example of only one module so you can imagine the size of each module.
Card Production Module
Bulk Card Generation
Bulk Card Export
Bulk Card Request
Card Operations
Card Operations Approvals
Card Printing
New Card Requests
Pin Generation
Pin Printing
This application is a product, not a project and as a product it is configurable. Even the UI is configurable. I have been working on this application as a full-stack developer. Since it's pretty old the state management library that we are using is flux. With state management, the development speed is a little slow but the tradeoffs are better with us not being worried about state management. By far the application has been able to handle huge changes and things which seemed unachievable. Stability has also been a key element throughout this period.
On the back-end, we have Restful services build using Dot Net which supports both MSSQL Server or Oracle depending on the client's needs/feasibility.
After countless react.js projects, I summarized a domain oriented and practical architecture in my blog post.
It is the absolute best practice that I applied many times, enjoy:
http://denislutz.com/domain-architecture-for-react
I am working on a pet project ( web application ) and I was wondering if I should use react because it would be easy to create native apps from this code (in future if I need to).
And if the answer is yes, what are the best practices to follow for
most resuse?
If the answer is no, can you recommend an alternative?
Some more information about my situation.
I am relatively new to react and my alternative will be good ol' html with bootstrap and jquery. I am considering using asp.net mvc and web api.
Sharing app logic between a React Web app and a React Native app, while keeping the individual component rendering unique to each platform is possible!
In my opinion, it is a great option we have available. I will give you an overview of the approach and a few advices.
In an ideal world, we would be able to share 100% of the code. As far as I know, that isn't possible, but still we can share a lot of the code. Although React Native is like React, it is very important to note that the rendering code is different. Instead web things like <div> or <span>, you use React Native components like <View>, <Text> and other built-in components.
However, the business logic in most cases is just JavaScript though and that's one of the important things which we can share!
The plan
Based on the Flux architecture you are using, it would mean that your store(s), reducers, actions would be shared code, as well as most of the business logic (inside services or whatever) and the constants and utilities too.
The UI layer would then be written specifically for each native platform using React Native and for web using React. Not only because it’s necessary to replace the HTML elements with React Native components, but also because the components will probably have a very different behavior on the mobile app.
Some General Guidelines / Advices
Consider a good architecture and code structure in order to share as much code (and application logic) as possible. Try to separate the UI presentation components (which will be different for each platform).
Take a look at the JavaScript Environment specifics in the React Native docs. When using React Native, you're going to be running your JavaScript code in two environments:
On iOS simulators and devices, Android emulators and devices. React Native uses JavaScriptCore which is the JavaScript engine that powers Safari. On iOS JSC doesn't use JIT due to the absence of writable executable memory in iOS apps.
When using Chrome debugging, it runs all the JavaScript code within Chrome itself and communicates with native code via WebSocket. So you are using V8.
While both environments are very similar, you may end up hitting some inconsistencies.
Consider the different strategies for sharing the code. In order to accesses shared code, the apps you're building doesn't have to all live in the same codebase or git repository.
More realistically, you would have two or more projects hosted separately, so an npm package is one of the easiest ways to share code between them.
This is easy as making a new package and setting it as a dependency inside each of your projects. For the path to the shared project, you can use a git repository rather than pointing to a public package on npm.
Even though you're building only the web app now, you could spend some time thinking about how you could generalize some of the shared code, so it is easier to re-use it in future.
It's possible and viable. You must have a view for each platform (web/android/ios), because each one have your components..
The business logic must be out of the view. Use flux can easy your project with native, because the it move the api interaction to a data layer, letting the view be just a view.