When we updated the doc successfully then directly
pass offline, the cache was not updated.
It is because a successful update didn't
update the cache of the doc-item.
Some api requests were served by the cache first,
which caused the data to be outdated.
This change makes sure that the api requests
are always served by the network first.
We will need to store more than a file for a document: multiple languages,
images, etc. For this, the document ID should be a folder and the content
a file in this folder.
Add a conf files to the service worker to store
the development urls. If someone wants to change
the urls, they can do it in the conf file, it is
more intuitive than changing the urls in the
service worker file.
Firefox does not trigger the request everytime the
user leaves the page. Plus the request is not
intercepted by the service worker.
So we prevent the default behavior to have
the popup asking the user if he wants to leave the
page, by adding the popup, we let the time to the
request to be sent, and intercepted by the
service worker (for the offline part).
We also add a toast to inform the user that the
document has been saved, it will make it more obvious
that the document has been saved if a firefox user
come back from the popup to the page.
We add a buildId to the service worker to force
the browser to update the service worker when
the buildId changes.
Before we were on the tag version, but
the browser was not updating the service worker
easily on the staging environment.
We override the perform_create method of
the DocumentViewSet to save the document with
the id provided if a id is provided in the request.
We do that because in offline mode we will create
the document locally and we will need to save it
with the id created locally to have our next
requests to the server to be able to find the
document with the id provided.
Add offline docs delete to the service worker.
We use the Network fisrt strategy, if
the network is down, we will delete the
doc in the indexDB.
When the connection is back, we will remove
the doc to the server.
Add offline docs create to the service worker.
We use the Network fisrt strategy, if
the network is down, we will create the
doc in the indexDB and serve it from there.
When the connection is back, we will send
the doc to the server.
Add offline docs update to the service worker.
We use the Network fisrt strategy, if
the network is down, we will update the
doc in the indexDB and serve it from there.
When the connection is back, we will send
the doc to the server.
This commit adds the service worker api to the
impress app.
The service worker api will cache the api calls
in the indexdb. We are using the network first
strategy to fetch the data. If the network is
not available, we will fetch the data from the
indexdb.
To do that, we create a custom plugin (ApiPlugin).
Add a new environment variable to enable or disable
the service worker in development mode.
By default, the service worker is disabled
in development mode, it can cause problems
when developing the application with the hmr.
It can creates useless log in the console
as well.
We can easily enable it by setting
NEXT_PUBLIC_SW_DEACTIVATED to false in the
.env.development file.
We will use this new var to not use the service
worder with the CI as well.
The initial doc was named pad in reference to
the "NotePad de l'Etat", but we renamed it
doc to clearly dissociate the 2 sites.
Doc is also a small reference of google doc.
Service worker added some flakiness, we
activate the sw only if not from the CI.
We add as well the email of the user added in a
doc to the toast message. This way we can check
if the user was added correctly, this will remove
some flakiness in some tests.
Add a offline mode support from a service worker.
The service worker will cache the assets and the
visited pages to be able to work offline.
Created a fallback page for when the user is offline
and tries to access a page that is not cached.
In collaborative mode, only the first document
connected was being shared. This was due to the
fact that the webrtc server was managing only
one connection at a time. This commit fixes this
bug by managing multiple connections.
The upgrade to react@18.3.1 has a compatibility
issue with next@14.2.3. It creates a error warning
about the fetchPriority prop. This commit fixes the
issue by downgrading react to 18.2.0 as it was
before the last upgrade.
The next.js team is already aware of the issue and
it will be fixed in the next release.
Add some recents changes:
- (frontend) manage members (update role / list / remove)
- (frontend) change logo
- (frontend) pdf has title doc
- Fix the break line when generate PDF