There was an implicit dependency on the scroll handler that wasn't correct, since it would trigger scroll-to-top at unexpected times. Splitting the effect into two solves the issue at no cost.
The field values of 'auth_type' have changed. The accesses might need to be updated in the database (and the migration pattern is not easy to guess). See https://git.weboob.org/weboob/weboob/commit/8ded0aa680ac23679c99cb74f1db00e81688ef0b
and
https://git.weboob.org/weboob/weboob/blob/master/modules/caissedepargne/module.py#L53-57
This MR fixed the following problem:
Observed behavior before fix :
Expected behavior :
The fix allows to have the expected behavior.
Antoine (44ccd088) at 08 May 10:40
[client] Scroll to the top of the infinite list only on mount, not ...
... and 534 more commits
This MR aims at reducing the main bundle size from 1.58MiB to 1.24MiB (in production) by lazy loading the charts more intelligently.
The first commit extracts the selects from all the chart files to put them in a single file (one of the reason the charts were included in the bundle was due to the selects being shared between lazy-loaded modules and non lazy-loaded ones.
The second commit exposes the charts from a single file and lazy load all of the charts from there.
The file charts/charts.js
is not written in ts
because this would require modifying the target version of JS of ts-loader
, which I prefer to leave it as is (it seems we are not very consistent across babel, ts etc see #1036 ).
I would expect that the category select in the "bulk edit" pane allows to create a category, the same way the category select in the operation list does.
I think the main problem which bothers me in this behaviour is that resetting the form (by clicking on the "clear search" button) keeps the "select all" active.
When getting budgets for a given period, if the budgets don"t exist for this period, the server create them. However, if you try to get budgets, for the same perdiod, twice in a very short time (we talk about ms, but in my case due to a bug in my code, it happened), the budgets to be created might not be already in the database when the second request reaches the server, leading to create twice the budgets.