The methods are trivial, and we cannot centralize the keys since they will be
different for different apps. So an abstraction for this is not beneficial.
Also move the next specific dev build check to @/next
It is not mentioned as a dependency in the SSR page
> For v10 and above, SSR just works in Next.js.
>
> https://emotion.sh/docs/ssr
Tested by - yarn dev, yarn preview:photos
This is no longer needed for emotion > 10
> For v10 and above, SSR just works in Next.js.
>
> https://emotion.sh/docs/ssr#nextjs
Tested with
- yarn dev:*
- yarn preview:*
This change screws up the CSS in places in dev mode though.
- Use the shared yarn monorepo configuration
- styled-components => emotion (since that's what the rest of the code uses)
- Remove Sentry (since it's gone elsewhere)
Fix an infinite loop of navigation under the following conditions: key
is valid
but token is not present.
Fix is to match the condition used in both gallery
if (!key || !token) {
and the root page.
They seemed to have diverged in commit
c3304571a9.
Was able to reproduce this when launching the desktop app such that the
key was
picked up (possibly from a prior installation) from the secure keychain,
but the
token was not found. I feel this is also a fix for a similar navigation
loop
recently reported by QA but unreproducible so far.
From discussions, it seems that it was pre-emptively added but not specifically
requested by a customer. We can bring this back later if needed, or at least
offer better options to clean it, but for now I'm pruning the IPC surface to
reduce the amount of work needed for handling contextIsolation and sandboxing.
This was found useful by @Bramas when building a Dockerfile of the web app
itself. See https://github.com/ente-io/ente/pull/1065.
Now, the GIT_SHA environment variable can just be undefined if we're not in a
git repository, and the code using it deals with that case explicitly.
**Tested by**
Temporarily inverted the isDevBuild flag, tehn
1. Ran the build normally and verified that the SHA continued to appear in the logs.
2. Ran the build after copying to a standalone folder without an associated git
repository and verified that the SHA was skipped without causing the build to
fail.
Sentry has a measurable impact on page load, a metric that I'm keen to
improve. Apparently by default it loses us 8-9 page speed points, though that
can be reduced to 3-4
(https://github.com/getsentry/sentry-javascript/issues/9179).
All of this is doable, but there are bigger tasks to deal with. This is not to
say that Sentry won't be useful again at some point, when we have time to deal
with it better. But right now, we discussed that it's just better to remove
Sentry instead of piling on to the sunk cost.
