When using RTK Query, you abstract away all the state management that comes with data fetching -- you call an endpoint and the documents are loaded into a variable, ready for use. Like so:
const {data: rangesInfo = []} = useGetRangesQuery(userId);
Let's say this rangesInfo variable contains a uniquely identifying ID, uuid, as well as a number, rangeValue, which specifies its position. This number can run from 0 to 100. For the sake of this example, let's imagine these ranges describe a user's food preferences. John is a 0 for sushi and a 100 for pizza. And as the end user clicks around the website, they can load other users' preferences, and so this set of ranges is constantly updating.
This all works fine -- you can call rangesInfo.map(range => <RangeComponent key={range.uuid} rangeValue={range.rangeValue}/>), and this will render a collection of children components, which all know how to display the UI of the actual HTML input[type=range].
But when using an range slider input in React, you must choose between either a controlled or an uncontrolled input. React's preference is for the input to be controlled by the state of its parent. In this case, the state of its parent is an RTK black box, and if you want to modify the cached data you must invalidate it, typically by triggering a mutation. This is RTK Query's term for a POST or an UPDATE request that will affect data in your backend. The thing is that in Chrome, a range input's onChange event triggers dozens of times a second, and it seems ridiculous to pummel your API with 40 requests when only the last one makes a difference.
That means we have to go with an uncontrolled component. The problem then becomes updating the display of the range when the props change. Because the props do change -- RTK is working fine -- but the props no longer have any bearing on the position of the range's value. (Remember, if you want to control an input's value via prop, you're no longer described an uncontrolled component!). If we could guarantee that the child components were remounted every time their props changed, we should be in the clear, but that wasn't my experience.
Even though those RangeComponents were given unique ids, and even though the docs suggest that this is sufficient, the new data was out of sync. When I loaded the page, I had User 0's info, and then I clicked on User 1 I still saw User 0. When I clicked on User 2, now User 1 popped in, and so forth.
My ultimately hacky solution was to attach a ref to the input range's DOM, and then use a side effect to dictate the its value, like so:
useEffect(() => {inputRef.current.value = props.rangeValue})
This solved my consistency problem, but introduced a ton of jank to the UX -- when I set the input range to a new state, it flickers back to its original position briefly.
Is there a way to solve this issue while staying in the RTK Query paradigm?
The no-jank, no-ref-necessary solution: Be extra sure that your child component's key is unique, because RTK is going to rerender it multiple times, and the render that "sticks" may not have the updated props at that point.
My fix was to append the value of the range to the key. So now the code looks like:
rangesInfo.map(range => <RangeComponent key={range.uuid + rangeValue} rangeValue={range.rangeValue}/>)
By linking the props and the keys together, you're guaranteeing that React will remount the child component.
Hope this saves somebody some time!
Related
WARNING: This question is specific to react-admin framework
I'm trying to do an in app manual, that uses data from server to load content pages. To doing so I'm doing a custom page that fetches manual pages on componentDidMount. In this function I call react-admin crudGetList(resourceName, pagination, sortingById, filters), where filters is {and:[{condition},{language: currentLanguage}]} since I want to have the manual in different languages. I noticed that having pages in different languages in database and using crudGetList action with filters fetches the correct instances, however the state maintains old data. For example if I initially fetch data in English language, change language and go back to manual page, redux state will have pages for both languages instead of the current selected one.
Is this expected behaviour? Making the new request for manual pages shouldn't replace redux-state data to data coming from request? If is not expected should I open an issue?
React-admin uses a pattern called optimistic rendering. That means that if the app has fetched some entities in the past, if it needs to display these entities, it first shows the stale entities, then fetches the backend, and if the response differs, re-render the screen with up to date data.
For instance, when a user fetches a list of posts, react-admin stores these posts in a dictionary indexed by id:
{
123: { id: 123, title: "hello" },
456: { id: 456, title: "world" },
...
}
React-admin also stores the list of identifiers that the list should display:
[123, 456, ...]
Using these two properties, react-admin can now display the list. But it can also display the detail of a post without hitting the server first. So when a user clicks on an item in the list, react-admin uses the data from the first structure to display it right away, without waiting for the server response.
The purpose of optimistic rendering is performance: since the user doesn't need to wait for a round trip with the server, the interface is super snappy.
In your particular case, I understand that this can cause problems, because the store contains stale data that is not in the desired language. I suggest that you create a custom saga, which reacts to the language change action, and clears the store to avoid this kind of problem.
Check the documentation for custom sagas in the react-admin site:
https://marmelab.com/react-admin/Admin.html#customsagas
You have to configure how the redux store responds to new incoming data.
More specifically, this is what a "reducer" is for; your "action" (in your case crudGetList) feeds the data into the "reducer", which is just a function with instructions to the store on how it should adjust its shape based on the new data.
Somewhere in your app there's probably a reducer that responds to your fetch action, but it's configured to just shove the new results alongside the old, rather than replace them. It's very difficult to know, however, without seeing the code describing the entire redux "cycle".
The redux docs are excellent. I'd start there and make sure you have a good understanding if the entire flow of data through redux, and then go hunting for that reducer.
https://redux.js.org/basics/reducers
I need to implement an infinite scroll, that is, as the user scrolls in a grid that has "potentially" thousands of items. Initially I have an SDT and it is the one I show on the grid.
The idea is that:
The SDT loads from 20 to the cursor position
Show those 20 in the grid
Save the cursor position
This should be quick. As the user scrolls down, cycle 1, 2 and 3 are repeated until finished. So as not to overload the grid.
The most similar thing I found in the wiki is this:
http://wiki.genexus.com/commwiki/servlet/wiki?21311,HowTo%3A+External+Services+%28Scenario2%29,
Where variables count, Start (to say how many to load and from which position of the query to load) and the sdt that load the values are defined. The point is that it is not clear to me how it works.
It loads in LOAD but nowhere do I see that the value of the Start variable is updated so I would always be loading the same 20 items.
If someone implements something so I can approach an explanation, some clue or a welcome xpz !!
Greetings and thanks
First of all, grids based on attributes already have this paging/infinite scrolling behavior on by default. I assume you are asking about grids based on variables.
The values of the &start and &count variables are automatically managed, and sent, by the GeneXus Smart Devices client application. The idea is that the service just needs to return the records in this range, and the client will automatically request more as the user scrolls.
Although it shouldn't have an effect on the service's implementation, the particulars are:
&start has the current (total) number of records returned by the service so far.
&count is a fixed value. It's the one set on the Rows property of the grid.
Therefore, the first request will have &start = 0 and &count = 10 (by default). The second request will have &start = 10 and &count = 10, then &start = 20 and so forth.
Note: It's important that if the client requests X elements, then exactly X are returned by the service. If this doesn't occur, then the client will assume that the data source is exhausted, and will make no more requests.
In Redux, every change to the store triggers a notify on all connected components. This makes things very simple for the developer, but what if you have an application with N connected components, and N is very large?
Every change to the store, even if unrelated to the component, still runs a shouldComponentUpdate with a simple === test on the reselected paths of the store. That's fast, right? Sure, maybe once. But N times, for every change? This fundamental change in design makes me question the true scalability of Redux.
As a further optimization, one can batch all notify calls using _.debounce. Even so, having N === tests for every store change and handling other logic, for example view logic, seems like a means to an end.
I'm working on a health & fitness social mobile-web hybrid application with millions of users and am transitioning from Backbone to Redux. In this application, a user is presented with a swipeable interface that allows them to navigate between different stacks of views, similar to Snapchat, except each stack has infinite depth. In the most popular type of view, an endless scroller efficiently handles the loading, rendering, attaching, and detaching of feed items, like a post. For an engaged user, it is not uncommon to scroll through hundreds or thousands of posts, then enter a user's feed, then another user's feed, etc. Even with heavy optimization, the number of connected components can get very large.
Now on the other hand, Backbone's design allows every view to listen precisely to the models that affect it, reducing N to a constant.
Am I missing something, or is Redux fundamentally flawed for a large app?
This is not a problem inherent to Redux IMHO.
By the way, instead of trying to render 100k components at the same time, you should try to fake it with a lib like react-infinite or something similar, and only render the visible (or close to be) items of your list. Even if you succeed to render and update a 100k list, it's still not performant and it takes a lot of memory. Here are some LinkedIn advices
This anwser will consider that you still try to render 100k updatable items in your DOM, and that you don't want 100k listeners (store.subscribe()) to be called on every single change.
2 schools
When developing an UI app in a functional way, you basically have 2 choices:
Always render from the very top
It works well but involves more boilerplate. It's not exactly the suggested Redux way but is achievable, with some drawbacks. Notice that even if you manage to have a single redux connection, you still have have to call a lot of shouldComponentUpdate in many places. If you have an infinite stack of views (like a recursion), you will have to render as virtual dom all the intermediate views as well and shouldComponentUpdate will be called on many of them. So this is not really more efficient even if you have a single connect.
If you don't plan to use the React lifecycle methods but only use pure render functions, then you should probably consider other similar options that will only focus on that job, like deku (which can be used with Redux)
In my own experience doing so with React is not performant enough on older mobile devices (like my Nexus4), particularly if you link text inputs to your atom state.
Connecting data to child components
This is what react-redux suggests by using connect. So when the state change and it's only related to a deeper child, you only render that child and do not have to render top-level components everytime like the context providers (redux/intl/custom...) nor the main app layout. You also avoid calling shouldComponentUpdate on other childs because it's already baked into the listener. Calling a lot of very fast listeners is probably faster than rendering everytime intermediate react components, and it also permits to reduce a lot of props-passing boilerplate so for me it makes sense when used with React.
Also notice that identity comparison is very fast and you can do a lot of them easily on every change. Remember Angular's dirty checking: some people did manage to build real apps with that! And identity comparison is much faster.
Understanding your problem
I'm not sure to understand all your problem perfectly but I understand that you have views with like 100k items in it and you wonder if you should use connect with all those 100k items because calling 100k listeners on every single change seems costly.
This problem seems inherent to the nature of doing functional programming with the UI: the list was updated, so you have to re-render the list, but unfortunatly it is a very long list and it seems unefficient... With Backbone you could hack something to only render the child. Even if you render that child with React you would trigger the rendering in an imperative way instead of just declaring "when the list changes, re-render it".
Solving your problem
Obviously connecting the 100k list items seems convenient but is not performant because of calling 100k react-redux listeners, even if they are fast.
Now if you connect the big list of 100k items instead of each items individually, you only call a single react-redux listener, and then have to render that list in an efficient way.
Naive solution
Iterating over the 100k items to render them, leading to 99999 items returning false in shouldComponentUpdate and a single one re-rendering:
list.map(item => this.renderItem(item))
Performant solution 1: custom connect + store enhancer
The connect method of React-Redux is just a Higher-Order Component (HOC) that injects the data into the wrapped component. To do so, it registers a store.subscribe(...) listener for every connected component.
If you want to connect 100k items of a single list, it is a critical path of your app that is worth optimizing. Instead of using the default connect you could build your own one.
Store enhancer
Expose an additional method store.subscribeItem(itemId,listener)
Wrap dispatch so that whenever an action related to an item is dispatched, you call the registered listener(s) of that item.
A good source of inspiration for this implementation can be redux-batched-subscribe.
Custom connect
Create a Higher-Order component with an API like:
Item = connectItem(Item)
The HOC can expect an itemId property. It can use the Redux enhanced store from the React context and then register its listener: store.subscribeItem(itemId,callback). The source code of the original connect can serve as base inspiration.
The HOC will only trigger a re-rendering if the item changes
Related answer: https://stackoverflow.com/a/34991164/82609
Related react-redux issue: https://github.com/rackt/react-redux/issues/269
Performant solution 2: listening for events inside child components
It can also be possible to listen to Redux actions directly in components, using redux-dispatch-subscribe or something similar, so that after first list render, you listen for updates directly into the item component and override the original data of the parent list.
class MyItemComponent extends Component {
state = {
itemUpdated: undefined, // Will store the local
};
componentDidMount() {
this.unsubscribe = this.props.store.addDispatchListener(action => {
const isItemUpdate = action.type === "MY_ITEM_UPDATED" && action.payload.item.id === this.props.itemId;
if (isItemUpdate) {
this.setState({itemUpdated: action.payload.item})
}
})
}
componentWillUnmount() {
this.unsubscribe();
}
render() {
// Initially use the data provided by the parent, but once it's updated by some event, use the updated data
const item = this.state.itemUpdated || this.props.item;
return (
<div>
{...}
</div>
);
}
}
In this case redux-dispatch-subscribe may not be very performant as you would still create 100k subscriptions. You'd rather build your own optimized middleware similar to redux-dispatch-subscribe with an API like store.listenForItemChanges(itemId), storing the item listeners as a map for fast lookup of the correct listeners to run...
Performant solution 3: vector tries
A more performant approach would consider using a persistent data structure like a vector trie:
If you represent your 100k items list as a trie, each intermediate node has the possibility to short-circuit the rendering sooner, which permits to avoid a lot of shouldComponentUpdate in childs.
This technique can be used with ImmutableJS and you can find some experiments I did with ImmutableJS: React performance: rendering big list with PureRenderMixin
It has drawbacks however as the libs like ImmutableJs do not yet expose public/stable APIs to do that (issue), and my solution pollutes the DOM with some useless intermediate <span> nodes (issue).
Here is a JsFiddle that demonstrates how a ImmutableJS list of 100k items can be rendered efficiently. The initial rendering is quite long (but I guess you don't initialize your app with 100k items!) but after you can notice that each update only lead to a small amount of shouldComponentUpdate. In my example I only update the first item every second, and you notice even if the list has 100k items, it only requires something like 110 calls to shouldComponentUpdate which is much more acceptable! :)
Edit: it seems ImmutableJS is not so great to preserve its immutable structure on some operations, like inserting/deleting items at a random index. Here is a JsFiddle that demonstrates the performance you can expect according to the operation on the list. Surprisingly, if you want to append many items at the end of a large list, calling list.push(value) many times seems to preserve much more the tree structure than calling list.concat(values).
By the way, it is documented that the List is efficient when modifying the edges. I don't think these bad performances on adding/removing at a given index are related to my technique but rather related to the underlying ImmutableJs List implementation.
Lists implement Deque, with efficient addition and removal from both the end (push, pop) and beginning (unshift, shift).
This may be a more general answer than you're looking for, but broadly speaking:
The recommendation from the Redux docs is to connect React components fairly high in the component hierarchy. See this section.. This keeps the number of connections manageable, and you can then just pass updated props into the child components.
Part of the power and scalability of React comes from avoiding rendering of invisible components. For example instead of setting an invisible class on a DOM element, in React we just don't render the component at all. Rerendering of components that haven't changed isn't a problem at all as well, since the virtual DOM diffing process optimizes the low level DOM interactions.
If I lock my phone while running my application and unlock it say after 30 minutes or 60 minutes, my screen appears blank. All my data (its a huge list compare it to a user's twitter feed) which was in an Observable collection in my ViewModel has disappeared. When I refresh I get NullReferenceException. Note that I am not handling any state save while locking and unlocking the phone. Is that the reason for the loss of my data? How can I handle it? Since there is a limit on the state data which can be saved of 4Mb Max, will it affect the functioning of my application even if I do implement it?
[Update]
I have tried the following things:
1) http://www.scottlogic.co.uk/blog/colin/2011/05/a-simple-windows-phone-7-mvvm-tombstoning-example/
2) http://www.scottlogic.co.uk/blog/colin/2011/10/a-windows-phone-7-1-mango-mvvm-tombstoning-example/
and many more.
The problem which I now face is that my application's viewModel contains an observable collection which I have binded to the UI. This observable collection is a collection of my user-defined class which contains complex data members. One of them is a dictionary. When i try to save my viewModel using XMLSerialization it throws an error as XML serialization doesn't support Dictionary.
I have also tried to write my viewmodel after Data contract serialization onto the IS during App_Deactivated and retrieve it on App_Activated. But my collection is null on resume. On opening the IS file it shows that the collection was not written onto the file. Am I missing some key ingredient in-order to solve this problem?
Note: I need my list. I cannot refresh data.
I'd suggest that this is the wrong approach.
Tombstoning is designed to allow you to save your state, not your data. You want to store the following:
The page you're currently on
The parameters, if any, that were used to get your list of data that you are currently showing
Any selection state (has the user selected a row, etc)
Any page state (is it in edit-mode, etc)
Not all of these things will apply, but it should provide you with an idea of what you should be storing.
This will be a significantly smaller set of data using simple data types rather than large chains of complex objects.
So:
Store the properties/parameters that you use to get your data
When the app resumes go get your data again using the params. If this take a while give the user some form of progress notification. If you can't accurately do this then display activity on the screen until the load finishes so the user knows that something is happening.
In my application, users have a list of items that they can put in any order they like. The database schema looks like this:
Items
+ Id : int
+ Name : string
+ Order : int
so when the user puts things in order, it sets the Order field accordingly, so that I can sort it later. Great.
Now, I want to make the sort ajax-y, such that the user can drag and drop items into order (and use up/down arrows), and it will just automagically save everything. (If you're familiar with Netflix, they do a similar thing.)
The issue I'm having is that in order to persist the user's changes as they make them, I will need to do an AJAX call every time they do something. If the user moves an item from position 10 to position 1, that implies that I have to update 10 records in that little ajax call. Meanwhile, the user may have queued up 3 more AJAX calls to update other records.
This seems inefficient and like it might be error prone (due to race conditions and so on, if the AJAX calls take a long time.) Should I be worrying about this? Is there a more efficient way to do this? If it makes a difference, I expect most users will have fewer than 5 items to sort.
Since Javascript can't synchronize code, I agree that it would be difficult to implement code that would be sure to avoid race conditions, although I did find this article on implementing a Mutex in Javascript.
However, personally I think that rather than choose an option that is likely to result in race conditions, I would go with one of the following options:
Create a save button above the items, that when clicked will save the order to the database.
Create a timer that will save the order every five seconds (or whatever), if something has changed. You would still want a save button for this, so the users could force a save.
I would lean towards the latter. Obviously in both cases you would want some visual cue to the users that they have unsaved changes (like changing the background color of the items, for instance). You would most likely want to implement something that makes sure the user wants to leave the page with unsaved changes if you go with either of those options (like in Gmail, when you have unsaved changes in an email that you are composing).