I have a problem with flux implementation on my app.
Heres the scenario:
We're a site builder plataform, we have pages where we don't know what will be rendering. Its completely dynamic, varying from user to user.
We have a lot of different components that may ou may not be loaded on the page and each component can have multiple instances.
What we need:
We need a FLUX structure that allows us to load only what we need from store and avoid unnecessary payload.
I have tried using Redux but the problems were:
Firstly we couldn't load all reducers at once but after a few research I built an interface capable of loading reducers on demand. But then I couldn't solve the problem with multiple instances from a component because the store file needs all states pre-refferenced :/
So, here's the question: How can I architect my app to use flux with dynamic pages and multiple instances from a component? Thanks in advance.
I think what you are trying to do is called "lazy loading". So you will just load components and pieces of javascript when they are needed.
Here you can find more information about (you need to generate more bundles of code with webpack):
https://blog.risingstack.com/react-js-best-practices-for-2016/
I will need this in a project in few months, but right now in our MVP we just need to make things run :)
Well, after a few (a lot) more research and attempts I'll implement a solution using React + Flux.Dispatcher + Backbone as suggested here:
https://www.toptal.com/front-end/simple-data-flow-in-react-applications-using-flux-and-backbone
===========================
Hope anyone has used that tip above. Worked nice for simple screens, got shit and slowly with complex pages.
Best way is to implement simple flux architecture as described in:
https://scotch.io/tutorials/getting-to-know-flux-the-react-js-architecture
https://blog.risingstack.com/the-react-js-way-flux-architecture-with-immutable-js/
Connect your components with a store via decorator and go for it, works simple majestic.
Hope it's usefull for someone.
Related
This question already has answers here:
React Native + React (for web) seed project
(6 answers)
Closed 4 years ago.
For a project, we need to have a Website and a mobile App (not a responsive Website) that both will consume my API. I used to work with React so I've checked a lot about React-Native for the mobile App part.
As I may understand, this require to create 2 distincts projects and it seems more efficient to do so (furthermore if these 2 projects don't share the same client). The problem is that, at a first look, both will use the same store... I don't want to dupplicate my store neither update both of them each time I update my API... The only difference I see between my React Website and my React Native App is the way they render. They will both have same functionalities. Can we go further by hypothesis that they will also share the same containers?
I try to open an issue on the github but they redirect me here to discuss about it.
So I want to know if you guys have THE best solution (clean & without bad surprises) to share code between React and React Native? If so, a tutorial will be very appreciate.
(Note: Searches were very time-consuming, React Native documentation should reserve a section about this subject...)
This was answered in this thread.
The overall idea is to have different entrypoints for each platform, and have the platform specific code (React for web and React Native for mobile) share common code like the Redux store.
An in-depth article can also be found in the thread I linked.
That being said, there are a number of tradeoffs and pitfalls to this idea one of them being dependency management, as you can see by this comment from the linked article:
I've just learned the shortcoming of this structure. By sharing a common package.json between native and web, you've glued them together by their common dependencies, the most important one being react. Let's say you upgrade to a version of react-native that depends on >= react#16, but your web app depends on some other library which depends on =< react#15. This exact thing has just happened to me, and I'm not finding an easy way out.
Another viable approach would be to transform the common areas of code into libraries you can export and import them to each separate project (mobile and web). That way you avoid the problems with the first option, but now you still have to maintain and update two separate code repos.
To answer your question the comments: I don't think there's anything wrong with having one project sharing code for both platforms, but it has to be planned very carefully so you won't break both your projects when trying to add new things. Try to start by planning your project structure so there's clear separation between web and mobile code and check if your dependencies are compatible with one another.
Here's a blog post that has an example project that should help you with designing your project.
EDIT: You could try React Native Web, but that's still in alpha so I wouldn't recommend it for work related projects (should be ok for school/personal projects though).
i'm currently expolring ReactJS
i saw NextJS and React Router
Can anyone tell me what's the pro cons between the two. I'm not sure if it's right to compare the two, but from what i see, react-router already has SSR feature. So whats the benefit of using NextJS?
Thanks!
Next.js (see also alternatives like GatsbyJS and After.js) are full featured SSR/static site frameworks, so you get a lot of features out of the box if you need to generate a SSR static site. These frameworks have solved lots of problems, so adding a feature becomes as simple as reading the docs, rather than researching and coding on your own.
If you code your own setup with a standard React app and react-router then you might find yourself running into a lot of complexity and edge cases when you dig into SSR.
In short, if SSR is a core requirement definitely consider using a SSR React framework.
Jed's response sums it up pretty much, but here are some clarifications:
React router allows SSR, but does not implement it. You still need to make a server script that, at least, renders the app to a string and serve that to the client. You may need to do other things, like serve static files. NextJS does that for you.
SSR comes with a few caveats that NextJS also covers, mainly initial asynchronous functions (fetchs from APIs, for example). In a custom made system, you'll have to determine which functions you should call, usually based on the route, and pass the data to the components, usually with Redux
I'm currently working on webs with both systems, and both have some pros and cons.NextJS has a specific way to declare routes and a very different way of moving through them, but making a custom system that deals with everything that NextJS covers is quite the work. I would not recommend making everything yourself unless it's really needed, and maybe check alternatives like Gatsby if asynchronous loads aren't a concern
I am quite new to web programming. I've started developing a single-page web application using React.js with a Node server.
I've read the tutorial, played with boilerplates, and quickly I understood React would take care only of the view aspect. So I tried to put my data-processing functions with the export keyword in a JavaScript file so I could use them in my React components. But that way was pretty "dirty" and it didn't feel satisfying at all.
Then I looked for a way to effectively separate the model and the controller from the view, so that I could completely change the GUI with little effort, and thus allow the project to grow and multiple people to work on it at the same time.
I've came across this article explaining the Flux architecture, and I saw a major implementation to use with React.js was Redux.js. I was quite surprised that I didn't see it at first, and now I wonder how much frameworks one has to use when working with JavaScript and Web.
My question is simple : is Redux.js all I need to effectively separate data, treatments and GUI components ? Or did I miss something else ? Are there any other major architectures you would recommend ?
Many thanks,
Redux is generally used to contain all the data that your app needs. It acts like a store which can pass the required data to the components that actually needs the data. For example, if you need a particular data fetched from an ajax request to be distributed among two components, then redux is a perfect fit. Whether you need redux depends on how your app is structured. If you have an app with a large number of components and most of these require data from your server or api, I'd suggest you go with redux. Once you learn it, it's incredibly simple. And yes, redux is all you need to separate data from ui. To get a nicely formatted structure, put together all your ajax requests under a folder and export it so that you can call it from the ui component. And when you receive the data pass the payload to the redux store which will automatically pass it to all the components which are connected to that particular reducer. For details on how to connect react with redux, check out their documentation:
https://redux.js.org/basics/usage-with-react
Remember not to confuse the state mentioned in redux with the state in react. Redux state refers to the application state. Do check it out and if doesn't work for you, another alternative would be flux.
I would like to implement a web application similar to messenger.com, also based on react framework. My problem is to manage the communication between List and Content components, as they're unrelated to each other. The render method of their parent component looks like this:
return (
"<" List "/>"
"<"Content "/>"
)
I want content component to refresh and load some data depending on selected list element, similar to messenger.com. Here's simple mockup
I've read a lot about redux, but I simply can't imaging how it should be implemented in this situation.
Here's also my whole react script running on the browser side: http://pastebin.com/ua928BEc
Sorry guys if it's a noob question I'm just starting with react :)
Many thanks for reading this,
Wojtek
Thinking in React is a great tutorial explaining state ownership in React and how components communicate. Once you get comfortable with it, you can try to implement this in vanilla React.
When you are comfortable in React but notice that some of your components get bloated because of all the state handling logic, you might want to check out a Flux implementation like Redux to offload the state handling to it. Getting Started with Redux is a set of free introductory videos to using Redux with React, and they are complemented well by the official basics tutorial.
But don’t rush into Flux or Redux until you understand React.
If the system is simple use a global messaging system such as pub/sub or signals: PubSubJS , https://github.com/Hypercubed/mini-signals , http://ctheu.com/2015/02/12/how-to-communicate-between-react-components/
If your application is more complex look into using a flux implementation (flux, redux...). You connect your UI components to flux store(s). You update the state in the store and the components will automatically re-render.
In order to solve this problem with a flux architecture.
Since you are working with a list and a content, then the selection of the list item you have, would call an action (get content of this list), that action would be dispatched, and would give the store the values you need in the content.
If you need further communication between components you can give some props to list / content components.
flux architecture description.
Flux example chat and others examples.
I'm in a project and my task is to build drop-down lists that lets user say his location without free text. I came to a point where I think that Flux is a really good way to built it, but I do not want to use React because of the dependencies issues. I would like to know if it is possible to build a flux app without React? And if it make sense?
Thank you!
Yes, you can use Flux without React since it really is just a data-flow architecture. Pretty much everything will be exactly the same -- except you won't be using React components. You would add a changeListener to the store, passing it a callback function to use when it processes an action.
I'm surprised, though, that you're concerned about using React due to dependency issues. What issues are those?