Closed omdxp closed 2 years ago
@ZibanPirate as for those Sentry related errors, I have tried their use cases and nothing happened, I believe those were existed during the dev process.
This is still a WIP, trying some hacks with memoizing components, if it will not help I'll normalize the redux state.
@ZibanPirate So I am doing the redux state normalization so the data can be selected the same way as in the database, this approach is way better than storing an array of objects (this method is suggested for all kind of states that are stored in redux as it is shown here).
The idea is to store for example the contributions
array as an object instead containing the byId
and allIds
properties:
contributions: {
byId: {
1: {},
2: {},
...
},
allIds: [1, 2, ...]
}
So when selecting all the contributions we can use something like this:
const selectContributions = (state: StateInterface) =>
state.contributeScreen.contributions.allIds.map(
(id) => state.contributeScreen.contributions.byId[id]
);
As you can see, now selecting an item would be much performant and it will not get out of sync, because the state is stored in a map of ids as keys and contributions as values. This can help the rendering process much efficient as it will not update all state but only the ones that are needed to be so not all components will re-render.
In our case, we should normalize the contributions with filters and options, so I am separating reducers accordingly than combining them in the contributionScreen
reducer. However, the utility type LOADABLE
will lose its effect as it is used in the contributions array for now, so I am thinking to put a new property called state
in the contributionReducer
that will be the value for it so what data type you may wanna use for it (LOADABLE<?>
?)
Description
This PR is dedicated to fix the lag for the filter component when refreshing contributions. It is also dedicated to fix some Sentry errors.
Fixes #375 Fixes #404 Fixes #405
Type of change