I am currently working on a tool that reads Excel files and displays them in a webApp. I split just like in Excel every worksheet in different tabs. When switching Tabs its taking like 2 seconds to this. That's because the Excel -> Json is 8000+ Rows long. It's probably redux that can't handle such massive Json's.
I did some research but I don't know if any of my solutions could work. And if so which one would be the best ?
immutable.js
redux-orm
Multiple Stores (But this is a "don't")
Maybe someone has a better solution for handling large data.
Redux is not the issue
Redux can handle huge amounts of data and should not be an issue in this case. It's more likely that it is a problem occurring from a rerender. Even tabs that are not in the view are likely to rerender as you swap between them, to test this remove extra tabs until you just have 2 and test clicking between them and seeing how long the rerender takes. Read the performance section in the docs here.
Optimize
When dealing with large amounts of data micro optimisations can really help. If you are using the Container component, Presentational component pattern then make sure you presentational components are using the PureComponent subclass. This will help you stop re-renders that eat memory.
The alternative to PureComponent is shouldComponentUpdate, you can specify the rules of when an update/rerender should happen.
Inside the react dev tools there is a check box that lets you check when a component rerenders please check that and start moving around your app. It will show you all of the pointless rerenders that are being fired.
Another way to help optimise is lazy load, "why show 8000 records when the screen can only fit 100?". This has 2 effects, you don't get data that you're not going to look at and you dont render cells that are not on the screen.
I hope this gives you some idea of how to move forward, good luck.
Related
End users in our react application have the ability to make payments to loans via a pop up. The initial problem that we encountered is that users could click the pay button twice (or heaven forbid more than twice) and this would create multiple payments throwing our accounting into disarray. We thus implemented a sort of lock state that, when triggered to true, shows a loading gif displayed in a div with a simple tweak of the z-index. The state is passed down to the pop up from 2 components above. Every now and then I get an error message displaying that there is a possible memory leak. I assume this has something to do with my fix.
I'm just wondering, is there best practice on how to handle this sort of "locking" situation with react while waiting on some other external system to respond? I've tried to do this via the front-end but I'm not 100% convinced that it's the best and/or only solution.
If you need some code to better illustrate the scenario then let me know and I'll work on adding some examples.
Thanks in advance for your advice!
There's plenty of ways of doing this. You could even had multiple layers to the process. On top of layering the page using a z-indexed loading screen, you could also disable the button depending on some form of state change.
Also, the memory leak could be from you not disposing everything after the life cycle of a particular hook ends. I would suggest you look at using useEffect as a starting point. There's a good chance that either your modal or loading indicator is causing this. Often times, this can be fixed by adding a dependency array to useEffect. Obviously, I am making a lot of assumptions here.
I am creating a common modal React component for my application to display a variety of different things. I would like it to be flexible enough to display both plain HTML and interactive React components.
I've gotten it to work by storing the displayable component in my Redux modal reducer. So far, I haven't run into any problems.
Has anybody taken this approach for any of before? I haven't been able to locate any examples of this online, so I'm unsure if this is bad practice. If so, is there another way you suggest this should be handled?
It may work, but I don't think you really need to do that. You shouldn't save the entire component in the store. Save only plain state, which should be serializable, and pass them as props to a component. The render() function of a component will take care of the render.
See the faq of redux:
Can I put functions, promises, or other non-serializable items in my store state?
It is highly recommended that you only put plain serializable objects, arrays, and primitives into your store. It's technically possible to insert non-serializable items into the store, but doing so can break the ability to persist and rehydrate the contents of a store, as well as interfere with time-travel debugging.
If you are okay with things like persistence and time-travel debugging potentially not working as intended, then you are totally welcome to put non-serializable items into your Redux store. Ultimately, it's your application, and how you implement it is up to you. As with many other things about Redux, just be sure you understand what tradeoffs are involved.
http://redux.js.org/docs/faq/OrganizingState.html#can-i-put-functions-promises-or-other-non-serializable-items-in-my-store-state
Also you can read the discussion of this thread: https://github.com/reactjs/redux/issues/1793
What are the disadvantages of using one big React component?
I have a deep experience using webpack, browserify, AngularJS, ES6, NPM and other similar web framework. I am new to React.
I want to create a single page app in React. I don't want or need testing. I don't need team friends to work on. I only need to make the product development as fast as possible. Make thing works. You can call it MVP. You can call it type lessm, or smart developement. If things work good in the future I can consider refactoring the project. I am the only developer who works on. I don't worry about perfromance issue (if it is just few ms)
The question is: All the articles said to make as much as possible many and small React components. In separate files. You can see the React-Starter-Kit. It is huge.
You can see that every component is a separate file.There is huge webpack.config.js file. Every component import many other things. If I also want Redux, I need to import the store, and make connect on every component.
I want to take different approach. I want to use React & Redux. But using only one component. Every inner element can Dispatch or execute events.
Is there is any problems in the future that I don't think about?
HTML:
<html><head><body></body></html>
JavaScript:
App=React.createClass(function(){
getInitialState:function(){
return {
openMore:'block'
}
},
openMore:function(){
this.setState({openMore:'visible'})
},
render:function(){
return (
<div>
I want to put all the HTML of the app
<span>
In one component that do everything.
<button onClick={this.openMore}>More Info</button>
<span> This way I beleive I will need to type less for development</span>
<b style={{display:this.getState().openMore}}>What are the disadvance of this?</b>
</span>
</div>
)
}
})
ReactDOM.render(App,document.getElementsByTagName('body')[0])
Well disadvantages are many. I will try listing them from what I have faced and observed:-
React was built on the concept to break page into components, so yeah the more you break the page into small components the more it is easier to use.
Its generally easy to track the code.
Its scalable
One component does not break other components.
Re-rendering is there only for specified components if they are isolated. If you have everything in a single component, the rendering would make your entire component load again, reducing efficiency.
Harder to test
Difficult to use with redux while passing actions and then connecting to store.
Your component should do only one job.
Cannot break the components into presentational and container components thus not utilising redux to full potential.
Not being able to use code spilt feature of webpack which increase speed of page due to partial code loading.
These are few things I personally faced. Next,coming to webpack configuration. I hardly have configured webpack file more than 100 lines and trust me those 100 lines make your life really easier. In fact basic configuration is just 10-15 lines which can generate your bundle.
Now,coming to problems in future, yes following would be problems:-
Difficult to scale up.
Difficult to test
Not utilising libraries to their potential
Difficult to manage component due to monolith behavior.
Hope it helps!!!
Having a single large file is fine. React was built on the maxims "No abstraction is better than the wrong abstraction" and having an API with a low surface area.
If you're not sure what problems your application is solving, then wait until you feel the pain of not having an abstractions before you create one.
If your application is likely to be in flux as its feature set isn't nailed down, then don't give yourself busy work by moving things around in different files.
If you don't have a website that is designed with reusable components that are intuitively separable, than don't separate it out into different components.
It is fine to use React just as a means of having a declarative syntax for what your html should look like in different states.
Having large components is bad due that you cannot simplify your code. Splitting your modules into smaller ones, will make it easier for you to maintain the code at a longer term, as well as finding out an error faster. Stack Trace is easier as well as it is more composeable, when having an implicit component.
FWIW, you can do a lot more separating your component into smaller ones, such as filtered props and an own state. The bad thing though, is that you can loose track of how the application is built up when you are looking at the build others have made.
I was wondering, how much state does really belong into the stores, and not into the components? I've read at some places that really all state should live inside the stores.
Would that include really component specific stuff, like input values (before submitting), input validation, if a modal is open, if something has been clicked etc?
What are the best practices here?
The obvious answer:
Keep component specific state (input value, modal open/ closed, stuff clicked, layout, formatting) inside the component state as much as possible.
And app specific state inside the store. Which includes, but is not limited to, stuff you send back and forth with a server.
That said, there is a lot of grey area here:
are filters applied to a search list component state? Or app state (if you save filters for future visits to the same page)?
are visited links in a global root-menu root-component state or app state?
if you are using optimistic updates, you may have a need to save user input stuff in the store, before and after communication with the server.
Some rules of thumb I use:
State belongs in component if it has the same lifecycle as the component (so if the state does not need to exist before the component mounts, and if it can be forgotten after the component unmounts)
If the state needs to be remembered when closing and reopening app, it is probably best put inside the store (where you do exchanges with server and/or localstorage)
If in doubt, start with state in component only: it keeps state much more localised (to the component) and keeps your code more manageable. At a later stage, you can always move the state to the store.
Keeping everything in flux stores may be benefitial for some apps.
So first, you should try to decide whether your app is like this.
If you're not sure whether a piece of state belongs to a flux store, then it's most likely that it doesn't.
You'll know when you need flux. And when you reach that level of understanding of whether such application architecture is appropriate for you, you'll probably know the answer to your initial question as well.
But of course it's nice to have some kind of specific guide, maybe just a mental guide, telling you when to keep state inside the component and when not to.
I'd go with these guides:
Is this state purely UI-related? Then you probably don't need to keep it in the store.
Is this state shared anywhere else outside the component? If not, then don't put it in the store. It's fine inside the component.
Can this state be persisted in the URL? If so, then don't put it in the store; put it in the url! It might be a search query of an input or a currently opened tab.
There may be exceptions to all of these, but in general I believe this to correspond well to the original ideas of a flux app.
P.S. Also I should say that there are a lot of talks saying that you should (may) keep all your UI inside an immutable state tree. That's how redux is introduced to lots of people. I think you should understand that while this is a great concept and it allows you so save/replay any user interactions, it is more often than not unnecessary and it's not what the main idea of Flux is about. And redux itself is a great flux tool that doesn't force you to keep all of the UI state in the stores.
View state specific to a component belongs in that component. App state which concerns many components belongs in a store.
It's debatable.
For example redux propose a pattern where ALL state belong in the store. Personally I think it is kind of impractical in many situations. It is very rare when I have any reason to store for example state of the button in the store.
But sometimes it can be advantageous. It is definitely easier to test when your whole app is stateless.
I'm getting to be a fan of David Nolen's Om library.
I want to build a not-too-big web app in our team, but I cannot really convince my teammates to switch to ClojureScript.
Is there a way I can use the principles used in om but building the app in JavaScript?
I'm thinking something like:
immutable-js or mori for immutable data structures
js-csp for CSP
just a normal javascript object for the app-state atom
immutable-js for cursors
something for keeping track of the app-state and sending notification base on cursors
I'm struggling with number 5 above.
Has anybody ventured into this territory or has any suggestions? Maybe someone has tried building a react.js app using immutable-js?
Edit July 2015: currently the most promising framework based on immutability is Redux! take a look! It does not use cursors like Om (neither Om Next does not use cursors).
Cursors are not really scalable, despite using CQRS principles described below, it still creates too much boilerplate in components, that is hard to maintain, and add friction when you want to move components around in an existing app.
Also, it's not clear for many devs on when to use and not use cursors, and I see devs using cursors in place they should not be used, making the components less reusable that components taking simple props.
Redux uses connect(), and clearly explains when to use it (container components), and when not to (stateless/reusable components). It solves the boilerplate problem of passing down cursors down the tree, and performs greatly without too much compromises.
I've written about drawbacks of not using connect() here
Despite not using cursors anymore, most parts of my answer remains valid IMHO
I have done it myself in our startup internal framework atom-react
Some alternatives in JS are Morearty, React-cursors, Omniscient or Baobab
At that time there was no immutable-js yet and I didn't do the migration, still using plain JS objects (frozen).
I don't think using a persistent data structures lib is really required unless you have very large lists that you modify/copy often. You could use these projects when you notice performance problems as an optimization but it does not seem to be required to implement the Om's concepts to leverage shouldComponentUpdate. One thing that can be interesting is the part of immutable-js about batching mutations. But anyway I still think it's optimization and is not a core prerequisite to have very decent performances with React using Om's concepts.
You can find our opensource code here:
It has the concept of a Clojurescript Atom which is a swappable reference to an immutable object (frozen with DeepFreeze). It also has the concept of transaction, in case you want multiple parts of the state to be updated atomically. And you can listen to the Atom changes (end of transaction) to trigger the React rendering.
It has the concept of cursor, like in Om (like a functional lens). It permits for components to be able to render the state, but also modify it easily. This is handy for forms as you can link to cursors directly for 2-way data binding:
<input type="text" valueLink={this.linkCursor(myCursor)}/>
It has the concept of pure render, optimized out of the box, like in Om
Differences with Om:
No local state (this.setState(o) forbidden)
In Atom-React components, you can't have a local component state. All the state is stored outside of React. Unless you have integration needs of existing Js libraries (you can still use regular React classes), you store all the state in the Atom (even for async/loading values) and the whole app rerenders itself from the main React component. React is then just a templating engine, very efficient, that transform a JSON state into DOM. I find this very handy because I can log the current Atom state on every render, and then debugging the rendering code is so easy. Thanks to out of the box shouldComponentUpdate it is fast enough, that I can even rerender the full app whenever a user press a new keyboard key on a text input, or hover a button with a mouse. Even on a mobile phone!
Opinionated way to manage state (inspired by CQRS/EventSourcing and Flux)
Atom-React have a very opinionated way to manage the state inspired by Flux and CQRS. Once you have all your state outside of React, and you have an efficient way to transform that JSON state to DOM, you will find out that the remaining difficulty is to manage your JSON state.
Some of these difficulties encountered are:
How to handle asynchronous values
How to handle visual effects requiring DOM changes (mouse hover or focus for exemple)
How to organise your state so that it scales on a large team
Where to fire the ajax requests.
So I end up with the notion of Store, inspired by the Facebook Flux architecture.
The point is that I really dislike the fact that a Flux store can actually depend on another, requiring to orchestrate actions through a complex dispatcher. And you end up having to understand the state of multiple stores to be able to render them.
In Atom-React, the Store is just a "reserved namespace" inside the state hold by the Atom.
So I prefer all stores to be updated from an event stream of what happened in the application. Each store is independant, and does not access the data of other stores (exactly like in a CQRS architecture, where components receive exactly the same events, are hosted in different machines, and manage their own state like they want to). This makes it easier to maintain as when you are developping a new component you just have to understand only the state of one store. This somehow leads to data duplication because now multiple stores may have to keep the same data in some cases (for exemple, on a SPA, it is probable you want the current user id in many places of your app). But if 2 stores put the same object in their state (coming from an event) this actually does not consume any additional data as this is still 1 object, referenced twice in the 2 different stores.
To understand the reasons behind this choice, you can read blog posts of CQRS leader Udi Dahan,The Fallacy Of ReUse and others about Autonomous Components.
So, a store is just a piece of code that receive events and updates its namespaced state in the Atom.
This moves the complexity of state management to another layer. Now the hardest is to define with precision which are your application events.
Note that this project is still very unstable and undocumented/not well tested. But we already use it here with great success. If you want to discuss about it or contribute, you can reach me on IRC: Sebastien-L in #reactjs.
This is what it feels to develop a SPA with this framework. Everytime it is rendered, with debug mode, you have:
The time it took to transform the JSON to Virtual DOM and apply it to the real DOM.
The state logged to help you debug your app
Wasted time thanks to React.addons.Perf
A path diff compared to previous state to easily know what has changed
Check this screenshot:
Some advantages that this kind of framework can bring that I have not explored so much yet:
You really have undo/redo built in (this worked out of the box in my real production app, not just a TodoMVC). However IMHO most of actions in many apps are actually producing side effects on a server, so it does not always make sens to reverse the UI to a previous state, as the previous state would be stale
You can record state snapshots, and load them in another browser. CircleCI has shown this in action on this video
You can record "videos" of user sessions in JSON format, send them to your backend server for debug or replay the video. You can live stream a user session to another browser for user assistance (or spying to check live UX behavior of your users). Sending states can be quite expensive but probably formats like Avro can help. Or if your app event stream is serializable you can simply stream those events. I already implemented that easily in the framework and it works in my production app (just for fun, it does not transmit anything to the backend yet)
Time traveling debugging ca be made possible like in ELM
I've made a video of the "record user session in JSON" feature for those interested.
You can have Om like app state without yet another React wrapper and with pure Flux - check it here https://github.com/steida/este That's my very complete React starter kit.