Squashed commit of the following:
commit 8636adab6455bea29659a6799a7f3aad9e7cc10d
Author: Johann150 <johann.galle@protonmail.com>
Date: Mon Oct 17 22:53:24 2022 +0200
fix: remove comment
commit 7ff8d45bfa2ed5c07c9a053e817604ef2eb115ad
Author: Johann150 <johann.galle@protonmail.com>
Date: Mon Oct 17 21:55:48 2022 +0200
fix paginations reloading
The Pagination type actually specifies that just the params property
should be a Ref.
commit 55fe9210c15785611603e3a7a2535ebf8008ea64
Author: Johann150 <johann.galle@protonmail.com>
Date: Mon Oct 17 18:55:54 2022 +0200
fix variable name
commit a464d1363bc8c62606a4d2acc148ce269973bede
Author: Johann150 <johann.galle@protonmail.com>
Date: Sun Oct 16 22:36:11 2022 +0200
fix: don't display empty drive message while loading
commit 52905b398f683ff3c71c2d5592851b2d2a428550
Author: Johann150 <johann.galle@protonmail.com>
Date: Fri Oct 14 22:19:13 2022 +0200
remove unavailable i18n strings
commit d491a71cbec05f991864a06b8e0001d40da006a3
Author: Johann150 <johann.galle@protonmail.com>
Date: Fri Oct 14 22:18:42 2022 +0200
client refactor: use pagination in drive component
This majorly refactors the drive component to use the proper pagination
component instead of reimplementing pagination.
The drive component is also refactored to use ref sugar (i.e. $ref).
This should also have better latency due to being a single query.
Furthermore, it's no longer a linear scan, since host is indexed.
Would be cool to simplify it further to a single query for blocks also...
Why exactly are blocks not in the db?
It works by having a day-long cache of
"when did we last successfully communicate with this instance?"
Anything over a specified threshold (1 month) will act as though the instance
is suspended - all outgoing jobs are dropped on processing.
The day-long cache is in place because the ordering is necessarily a
linear scan.
Once an instance comes back online, we will detect that is the case as soon as
we receive an activity from them (which will update the "last communicated at")
field.
Potential future TODOs:
* Improve the caching system, it's actually pretty inefficient as it is.
CacheBox with a call override?
* Think of ways to make it not-a-linear-scan, since the instances table can get
pretty big. It's around 4500 on toast cafe.
ChangeLog: Added
I'm not sure how it managed to work so far, but the function is the default
export, using the namespace like a function should not have worked,
maybe something under the hood was correcting it back
This is oriented on this paragraph from the AP spec:
> Additionally, if an object is addressed to the Public special collection,
> a server MAY deliver that object to all known sharedInbox endpoints
> on the network.
Refactoring this component could be done after changing its method of
receiving the list of available tabs by using slots to using an
ordinary parameter. This was possible because all uses of this
component just provided text as the tab labels.
Also removed unused imports of this component.
Also removed the use of the click-anime directive.
Reviewed-on: FoundKeyGang/FoundKey#184
The default value was chosen incorrectly in commit
ab84457c0e. To be backward compatible
the default value has to include all available notification types.
Constants were borrowed from `const.ts` from the backend but also
includes `WEEK`, `MONTH`, and `YEAR` constants as well.
Co-authored-by: Francis Dinh <normandy@biribiri.dev>
Reviewed-on: FoundKeyGang/FoundKey#183
Refactoring this component could be done after changing its method of
receiving the list of available tabs by using slots to using an
ordinary parameter. This was possible because all uses of this
component just provided text as the tab labels.
Also removed unused imports of this component.
Also removed the use of the click-anime directive.
The file i18n.ts was basically only a few lines that call into
scripts/i18n.ts. Instead of having the extra file it is just as good to
have the relevant code for i18n in one file. Since i18n.ts is
imported in many client components, while scripts/i18n.ts was only
imported in i18n.ts, the latter seems better to keep.
Added some more comments and translated the Japanese comments to
English.
This makes it consistent with `outgoingAddressFamily`, reducing
potential confusion.
For compatibility reasons, numbers are still permitted for `redis.family`
with the following mapping:
- `dual` = `0`
- `ipv4` = `4`
- `ipv6` = `6`
Changelog: Changed