We Keep Coding

Next.js favorite list best practice

I have a next.js application with redux and a node.js Rest-API. You can view items and as often you can store favorites.
Now the view component of the items and the favorites is obviously the same.
I have now two options how I can do it and I want to ask you what is best practice with next.js:
1.Option:
Have two routes. One called "search" and one called "favorites".
Pros:
Clean approach as everything is clearly separated from the root
Cons:
Have to remove full DOM and add full DOM just to show favorites - which is essentially the exact same view
2.Option: One route called "search" with a prop for the section
Cons:
Unclean IMO since I need to add a prop to many components
Pro:
For me seems to be way faster
Redux store is organized the following:
{
search:{
results:[],
total:0,
},
favorites:{
results:[],
total:0,
}
}

It's hard to provide a concrete answer to this question. Do you want one page for users to browse items, allowing them to filter by which ones they've favorited, or do you want one page for searching items regardless of which ones they have favorited and a separate page for finding favorites? This doesn't seem like a best practices problem, it's totally your choice. That said, I would probably prefer option 1 because that is how most applications do it. The fact that it is slow is weird—next.js tends to be very good about preloading. Give your page(s) a try in production mode—often Next.js is just slow to build them in development mode and the real page your users will face will be much faster.

React-Redux How to improve performance?

I am using the react-redux for one of my app, The design is quite difficult and performance required is very high. its actually wyswyg builder.
We have been using the react from last 2 months, Then we moved to the react-redux for the separation of code and improve maitainance, code readability and the parent-child approach headache ofc.
So, I have an array which has quite complex structure
This is how my state look a like:
const initialState = {
builder:{},
CurrentElementName:"",
CurrentSlideName:"",
.......
}
As redux recommend to have less data in particular object as possible, I have another 8-9 reducer which are divided from the main state.
My problem: builder object is very complex which has almost 3-4 levels down, objects and arrays, this all are managed runtime.
So, on the componentdidmount my application will call the server get the data and fill the builder:{}
builder:{
slidedata:[{index:0,controName:'button',....},{index:0,controName:'slide',....}],
currentSlideName:'slide1',
currentElementName:'button1'
}
This builder object is quite complex and depends on the user actions like drag and drop, changing the property, changing events, changing position this builder object is being changed by the reducer
let clonedState= JSON.parse(JSON.stringify(state));
//doing other operations
Every time some thing changes this object needs to perform certain complex operations, for ex, adding the new slide will do certain operations and add the slide to the current array called slidedata.
What is the best practice to fast this things up? am I doing something wrong?
I am not sure what is the wrong in this code, and as redux recommend I can not use the flat structure for this particular array as its managed run-time.
I am sure that component has the data which the component wants.
Is there any way to handle the big data? This iterations and changing the state is killing my performance.

Based on my current experience with React-Redux framework, Re-select and ImmutableJS make a perfect combination for your requirement.
Re-Select uses memoization technique on Javascript objects and have list of API's specifically dealing with these kind of large set of Javascript objects thus improving performance. Read the docs.
Note: One should wisely read the documentation before using this setup to churn the best of these tools.
You can either create your own boilerplate code using above libraries or use the one which i am currently using in my project.
https://www.reactboilerplate.com/
This boilerplate is specifically designed for performance. You can customize it based on your needs.
Hope this helps!

How can I improve the performance of passing around a large JSON object in React Native?

I'm building an app with React Native and on my transitions, where I'm loading more data, it's very slow and I'm wondering if there's a better way to structure my app to avoid these shutdowns, which get longer as the JSON file gets larger.
Let's say I have
var data = require('./data/data.json')
in my index view, I think pass this data to a view, which then splits it up to other views like items={data[section_name]} and it goes down recursively like that further down the hierarchy. Creating smaller dicts on each level. And even with small objects it is still quite slow.
The JSON files I'm working with are from 3-8 MBs.

I understand what you want do to with your big data in your project, because I did the same way before for my react-native app.
Actually, this way is fine, it's kind of loading the data once only, then we can retrieve hierarchy easily like items={data[section_name]}
However, the problem now is it may take a while for processing the big data!
Therefore, the idea is we should move the part of loading/initializing the data asynchronously, move it somewhere out of our view, so that the view's transition as well as its other things will not be affected! Then, when the data are being loaded/processed, we may show something like fade-in, fade-out effects, on the view, so it will take a short-time (300-1000ms). However, in my opinion, there may be a better way for this: when the application is opened for the first time, when the splash screen is being shown (for a few seconds, this behavior is common, we can load the big data in the background here!)
FYI, my application loads big data using ajax, it will even take longer than loading local files, but using my above-mentioned way, nobody complains about the data-loading speed ^^ (actually, users don't know and don't see where and when data are loaded, when the app goes to its home/top page, everything has been fully loaded)
Now it comes to the important part of my answer: I suggest you using Flux/Redux for this, maybe Flux is easier for you now, because Redux is kind of an improvement based on Flux (in either Flux or Redux, we will have a Store, and this Store will work asynchronously, you can store your big JSON data here):
https://www.atlassian.com/blog/software-teams/flux-architecture-step-by-step
Flux can be applied on reactjs and react-native of course, you may find there are several new definitions if you don't know about Flux or Redux yet, however, it's really worth reading and trying! After you understand it, it'll be very easy and then you can apply that architecture on whatever react project you like ^^

Redux architecture for text editor: dealing with coupled state

I'm building an app with React/Redux that is in some ways similar to a text editor. It's not a text editor exactly, but it's the same general paradigm. There is a cursor for placing new items. Items can be added, selected, deleted, etc.
I'm struggling with the best way to structure my reducers in a way that is in keeping with the spirit of redux. I have separate state slices representing the selection state, the text itself, the cursor state, and other settings. I think the "redux" approach would be to have reducers for each of these state slices, independently mutating state in response to an action.
However, in a text editor these state slices are a lot more coupled than at first glance. When you press a key, sometimes a letter will be added at the location of the cursor, and the cursor will move forward. If text is selected, however, the selected text will be deleted first. If you are in "insert" mode, text to the right will be "consumed". Or maybe a modifier key was down, and text isn't added at all.
In other words, the different state slices are very coupled and what happens in one depends on the current state of the others.
I've read the "Beyond Combine Reducers" section in the Redux manual and know how to share state between slice reducers, but this seems inelegant if the end result is passing the entire state to every slice reducer. The other thing I don't like about his approach is that each reducer would have to look at the overall state and independently come to the same conclusion about what its correct response to a particular action should be. Is that what I should be doing or I should be structuring my state differently somehow?
The alternative of one centralized reducer telling the cursor, the selection state, the content, etc. how to mutate is easier conceptually but doesn't seem to scale well.
I've also read that many times coupled state is a sign that your state isn't minimal and that you should be restructuring and using memoized selectors. However that doesn't seem to be the case here. The position of the cursor is not derivable from the text, nor is the selection state.
Lastly, I've also considered Thunk middleware as this is something that I've seen suggested for handling multiple/more complex actions. I'm hesitant because it seems like it is more meant for asynchronous dispatch and this is not that.
I'd like to understand the correct approach for designing this type of app that is most in keeping with the "redux" design pattern and understand any tradeoffs there might be if there are multiple ways forward.

I wrote that "Structuring Reducers" doc section, so nice to see that people are at least reading it and finding it useful :)
You're right that the idiomatic intended approach for Redux reducer logic is small reducer functions, organized by slice of state, independently responding to the same actions. However, that's not a fixed requirement, and there are definitely times when it makes more sense to consolidate some of the logic into one place.
It's a bit hard to give absolute specific advice without seeing what your state structure is and exactly what problems you're trying to solve, but overall, you should feel free to structure your state and your reducer logic in whatever way makes the most sense for your application. If it works better to have some of that logic in a more centralized reducer function that updates several nested pieces of state at once, go for it!
As a couple other observations:
Per the Redux FAQ question on "sharing state across reducers", one approach is to put more information into the dispatched action. For example, rather than dispatching {type : "KEYSTROKE", key : "A"}, you could dispatch {type : "KEYSTROKE", key : "A", cursorPos : 12345, ctrl : true, alt : false}.
Also, while thunks are a good place for basic async logic, they are also useful for complex synchronous logic as well, including inspecting the current app state. I have a gist that demonstrates some common thunk use cases.
Lemme toss out a couple more resources that may be of general assistance to you:
My React/Redux links list has a section linking to articles on writing reducers
My "Practical Redux" tutorial series demonstrates a few variations on reducer structures, including the post Practical Redux, Part 7: Form Change Handling, Data Editing, and Feature Reducers.
(As a side note, I'm also currently working on a blog post that will discuss what actual technical limitations Redux requires and why, vs how you are "intended" to use Redux, vs how it's possible to use Redux. Will take me a while to finish it, but keep an eye on my blog if you're interested.)
Finally, if you'd like to discuss things further, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com . Please feel free to drop by there and ask questions - I'm usually on there evenings US time, but there's always a bunch of people hanging out happy to discuss things.

Seems you are taking a huge task; probably you already know that, but creating a text editor from scratch is not an easy task.
Did you evaluated using an existing software?
Recently I used with success the super powerful Codemirror and integrated it with a React.js application. Codemirror already manage the concept of state of the document in a great way.
That means:
Codemirror instance fully manage the editor (AKA: the document)
React environment is attached to the document through callbacks and events.
If Codemirror doesn't fit your needs, take a look at it's code and internals description.

how do you folks handle complex state situations where order of operations is important?

I'm getting in to a situation where I have several interacting widgets (on a web UI), all of whom can be in multiple different states, and whose behavior depends on others the others. I'm running in to situations where, for example, a set of data gets sorted twice, or the data gets displayed before it's sorted, rather than the other way around. It's a little bit of a wack-a-mole problem, where I think I've simplified things and gotten it working, only to find out I've broken things somewhere else.
I have functions that do things like:
widgetAFunction
load data into widget B
tell widget B to sort the data
tell widget B to display the data
My love of code reuse makes me want to do something like write a loadData function in widget A that goes something like this:
widgetBLoadDataFunction
update data
sort the data
refresh the view
So that all widgetA has to do is call one function on widgetB. But then there are cases where I just want to sort the data, without updating the data, so I write:
widgetBSortFunction
sort the data
refresh the view
And then maybe I want a filter function
widgetBFilterFunction
filter the data
refresh the view
And maybe I want to be update the data but not sort it, so I have
widgetBNoSortLoadDataFunction
update data
refresh the view
It doesn't seem that complex, but I wind up with these really long, very brittle chains of function calls, or a bunch of very similar calls. As Martin Fowler would say, the code is getting a little smelly.
So, what other alternatives do I have? I did something on a recent project where I did a state machine kind of thing, where I registered a bunch of functions with a set of conditions, or states which would trigger their execution. That worked somewhat well, and I'm thinking that approach might be good to use again.
Does anyone know what I'm talking about here, and even better, can anyone point me toward some patterns that will help me get my head around this better?

What you need is a finite state machine implementation. Basically every finite state machine needs:
Events that the program responds to
States where the program waits between events
Transitions between states in response to events
Actions taken during transitions
Variables that hold values needed by actions between events
A good article from IBM teachs you a way of implementing it by means of Javascript.
Edit: Here is a FSM builder, so you don't have to build your own.

Fernando already mentioned FSMs, and gave good info and links. :)
In addition, I'll add that your classes should already incorporate enough state so that you're not worried about sorting twice, etc. I.e., widgetB.sort() should check if it's been sorted since last update and just return if so. There's practically no downside to doing this, and it can improve performance (and also guard consistency).