So i read somewhere about exposing a React component on the server which makes it importable to a different application, However im unable to find where i read this and cannot locate anything that would help me with this query.
So lets say i have several microservice applications they all essentially share the same Navbar component, my Goal would be to have the component in a central place that can be edited and updated and that would update all other components in other react applications, it would help with maintaining the code.
but in all actuality im not even sure this is possible. considering react components are built into the build folder any structural changes wouldnt be noticeable without rebuilding. But i know i read somewhere about this.
Related
I have to create multiple small React Apps that are modularly integrated on existing WordPress sites (using Shortcodes).
They might use the same state that is currently shared using react-hooks-global-state, which works fine.
However, since I've started using Recoil.js for other Apps, I'd like to know if it is or will be possible to also share global state (accross React instances) with it. The problem right now seems to be that we have to provide a RecoilRoot that must be nested above all components. Obviously, this doesn't work when having multiple React Apps, does it?
Thank you!
Definition of our requested Dynamic App
We Have to make an app with Dynamic Layout.
Our marketing team needs to change layout of page. for example ordering the components or maybe add new route to react app or maybe add or remove some component from some page.
Technologies that we are using
We are using typescript as our base language of create-react-app and redux for state management.
My Solution
My Solution for this is to generate .TSX file in server on changes come from a panel and build entire project with new files created by server.
I prefer to not use dynamic import, because user must waits for a api to get the page layout structure then client must import the components and after that every component request it's desired api call from server! Too much time waist!!
Your Idea
What do you think about this structure?
Is there any bottle neck that I may encounter? or maybe i didn't saw?
We will be doing our first project using React.
It will not be a Single Page App, but a Multiple Page App.
What I'm trying to figure out at the moment is : what's the difference between a component and an app.
If I only use components, can I still use Redux to have some state management on the current page ? Or do I need an app for this ?
Thanks for the information you can bring !
THoma
There is no special object called "React App". React Components build an "React App" by coming together.
But React Components are formed like tree structure. That means each component have a parent component so you can create a React Component that named "App" and can put another components inside it.
You don't need redux for state management in React Components.
I hope the answers have helped.
Your app may contains a single component and still it will be a react App. If you are using multiple components in a page you can still use react-redux. Redux is basically a container for your states and let suppose you need some state from one component to be consumed in another, Redux provide you a mechanism to make the communication efficient and predictable.
You can also look at the React Context APIs as an alternate to Redux.
An app is simply a component that holds the root of the work you are trying to do. For example an App may have the navigation menu, testimonials, adverts, content, login avitar etc.
If you are making a single App per page (For example a testimonial) then you would still have a SPA. For example, adding testimonials, searching, editing.
You should only use Redux if you are using a SPA with lots of different parts with data in common. If you are making a one-app-per-page and there is no cross over in data then you can simply using Reacts State/Props to hold your data.
Redux is good, but it forces you into a complex path your should try to avoid. If you find yourself wanting data from different domains (customers address and a list of testimonials) then you should use Redux.
If this is a new applications (green) then I strongly recommend you build the whole thing within a SPA using React-Router to control components. you can use frameworks like Next.JS to ensure the site remains small in size (dynamically loading script only when required).
I want to migrate my project from plain react to react redux, I am not new to React but new to Redux.
I have a fairly big web app written in React, dozens of React.js files.
most of them containing state's + passing variables between them.
including allot of Post/Get requests functions, implemented into at least half of my files.
I want to slowly move from plain react to react redux.
I wanted to ask if anyone have some article or can give an insight about migrating existing react project to react-redux.
I dont want to stop development for the sole purpose of the change but instead to slowly adapt to it.
is it possible ? is there a tool to help me do it ?
I saw some redux examples where entire render of app.js was surrounded by <Provider> </Provider>, does that mean every component inside <Provider> bracelet can not have it's own state ?
can I simply keep my old components as they are and put new ones into <Provider> </Provider> ?
Thanks in advance!
I saw some redux examples where entire render of app.js was surrounded
by , does that mean every component inside
bracelet can not have it's own state ?
The way react-redux works is by exposing a store prop, provided by the Provider. In order to consume it, or extract data from it you must wrap your component by it (not directly necessarily, but one of the parents must be a provider). In general in most apps you would simply wrap the entire application with a Provider, because for the most part, if you've chosen to introduce redux into your application, it is probably because your entire app needs some store.
Using redux does not mean that components can't have state. There is a big difference between global state - something that should be accessible to every component in your app (if the component chooses to "consume" it), and state that is private to a component - e.g. form changes before being sent to the server.
can I simply keep my old components as they are and put new ones into ?
Well, yes. But also - no. As I said earlier, you should probably start from the top and slowly drill down. Wrap your app with a Provider, and start moving your application state from the top-most component to the store. Once you get more comfortable with redux in general, you should start replacing the props you pass down the component tree with props from the state by connecting your inner components.
This way you can do it one component at a time without breaking existing logic.
I don't understand why we need Flux with React as React itself let's us maintain the state of the application. Every component has an initial state and the state can be changed by user actions or any other asynchronous JavaScript.
Why is React called as only a view library when it can let's us define state of the application and also update view whenever state changes. This is not what a view does....its what complete MVC does right?
For example: here is an Todo app build only with React and here is an Todo app build with Flux and React.
If we can build the Todo app with React only then why do we need Flux?
In theory you don't need flux.
In small applications you don't need flux for sure.
But what if your application consist of hundreds components? And one of your component is form. User populate this form and you send its content to server. And get response from server with new data.
And assume that this response data and data from form are necessary to other components.
Without flux:
You can move your data to root component and then distribute it down to all components. But if you need to distribute data from many other components too? This makes your application very complex.
with flux:
You move your data to stores, and all components which are interested about this data, can get it from there. You have better control on your application and source data.
I prefer redux (only one store and one source of truth)
edit:
Why is React called as a view library even if it can handle application state?
MVC is a software architectural pattern. It divides a given software application into three interconnected parts (models, views, controllers).
If we think about react and MVC it fit as View. But this is nothing wrong. It doesn't mean that you can use it only for views. It allows you to create normal applications.
But in other hand you can use it as view for other frameworks (for example you can use it with angular).
In other words it is very flexible library for many uses.
You don't NEED Flux the same you don't need MVC. They are both architectures and you can of course build something without using either.
Would you build a non-MVC app in 2016? Probably not, that doesn't mean that people didn't do it in the past.
Flux is awesome! But as most things in the tech industry is not always the right decision, things vary in a project requirement basis.
Probably the biggest selling point of Flux is that it tries to enforce the data flow in one direction, this means that you know for sure where the data is coming from. In a non-flux app the data for a component could be an own property, a property passed down the component tree, a local state variable, a state variable result of calling an API.
With Flux: "where does the data come from?". Answer: from the stores. Redux takes this further and only uses a single store.
Flux has been criticized because you need a lot of boilerplate code but again is a matter of tradeoffs.
At the end is always your call depending on your project needs.