Age | Commit message (Collapse) | Author | Files | Lines |
|
Unfinished, primarily for testing.
https://vndb.org/t20399.36
|
|
For completeness.
|
|
For some reason people manage to fail the old input validation even on
this form.
|
|
Main reason for this rewrite is that I realized that many mobile
browsers don't properly support reportValidity() yet. The new form code
still heavily uses the HTML5 validation API, but doesn't rely on
reportValidity() as much since it has CSS :invalid fallbacks. And even
if that fails, the error messages reported by the server are slightly
more useful.
Also removed the bot verification question as an experiment, might come
back if it turns out to be needed.
Also added a silly checkbox to check if people read checkbox labels.
Also used <input type="email"> to help mobile browsers select the right
keyboard.
|
|
elm.min.js.gz shrunk by 9919 bytes. user.min.js.gz is now 9681 bytes.
Not a totally fair comparison and those few bytes are completely
irrelevant, but it at least shows that I'm not making things more bloated.
|
|
Yak shaving at its finest. I was working on an edit form for the new
franchises system, but then realized that the form JS and HTML kind of
sucked and a completely new form isn't the best way to experiment with a
new implementation. I also had some ideas to improve the user edit form,
so decided to rewrite that first, but then realized it's better to lay
down a smaller foundation before doing the complex stuff. So here we
are, a completely useless rewrite of a tiny little login form.
But I did improve error messages a bit while I was at it.
There's still a bunch of unknowns regarding form implementations: to see
if there's a more convenient way to set custom validations; to see if
HTML5 validation works well with form tabs; to see if URL fragments can
be used to select form tabs; mobile-friendly form layouts (should be
easier with this new approach); dropdown search improvements, etc. The
user edit form should prove a good testing ground for all of that.
|
|
With a samesite cookie check, to see if that can be relied on.
|
|
|
|
Currently has 851 million password hashes, taking about 8G of space with
the current approach. It's simple and fast, so should be worth it.
inb4 complains about "why can't I use my password anymore!?"
|
|
+ update filters and APIs to respect the 'listread' permission.
|
|
|
|
|
|
Currently only added on VN listings in row view, but the goal is to add
this widget to other listings and pages as well. This should make it
easy to see whether a VN is on your list and to add/remove/edit your
list status.
The code is one of the messiest copy-paste jobs I've ever done. I'm
totally going to regret having to maintain this crap. But anyway, let's
first see how this UI is received.
|
|
Requires imagemagick built with webp support, of course.
They're still converted to JPEG, because I don't think the
size/compatibility trade-off is worth it.
|
|
|
|
Seems more efficient - no need to fetch and transfer those lists when
they won't be needed in the majority of cases.
|
|
Using a lazily loaded static list
|
|
It's still missing a few mod features, will add those later.
|
|
|
|
The image voting is now handled separately from form submission and
image IDs are validated when changed.
This abstraction is hopefully also usable for the VN form.
|
|
Completing the "General info" tab. This makes use of the new anime
titles import for validation and autocomplete.
It does have a bug, though, as it also autocompletes deleted AniDB
entries that happen to have been linked to old VN revisions. Need to
find a way to mark those for exclusion.
|
|
Because, apparently, some browsers ignore the client-side HTML5
validation attributes for textareas and some people will never learn
that the edit summary is a required field.
|
|
|
|
|
|
|
|
Lots of TODO's left to work on, but you have to start somewhere.
I've bumped the Docker image version because this change requires TUWF
commit 74aad378d49592df4359ea8a9f6f36d4a0013c04 (Elm decoder for structs
with more than 8 fields)
|
|
Lots of copy-pasting going on here. Meh.
Also added a couple of overdue server-side validations.
|
|
And a few minor styling fixes.
|
|
So much more convenient. \o/
|
|
|
|
This also changes the voting interface a little bit:
- Spoiler options are a bit more concise
- Mouse-over a button indicates what it does
- The -1 and -2 options are not available anymore
- Downvoted tags are hidden by default
- Moderators can now vote-and-overrule in a single go
|
|
endpoint
The new elm_api() function now creates an API endpoint (like json_api())
and generates a corresponding Elm module to interact with that API (like
elm_form()). The API endpoint URL is now derived from the name of the
Elm module, so there's no need to think of a separate URL and less prone
to making typos when using that URL from Elm.
Reduces the boilerplace a bit as well.
|
|
Now with BBCode preview, interactive board search, client-side error
reporting and lots of new bugs.
This took me far too long, turns out it wasn't such a trivial rewrite.
|
|
Fixes https://vndb.org/t2520/14#334 - I originally had some trouble to
do this because `load` doesn't actually reload the page if you're just
changing the hash. The `reload` following it handles that now.
The Redirect response is just cleanup, there's several places that could
benefit form it.
|
|
|
|
This ensures that the email address linked to a user is always valid and
actually belong(s|ed) to that user.
|
|
And add a small 'formField' function to shrink the Elm form generation
code a bit.
|
|
This is largely copy-paste from v3.
|
|
The insecure-password-change flow is now slightly more friendly. The
logout functionality has been hardened to use POST and require CSRF.
|
|
Most of this is copied from v3. I did improve on a few aspects:
- db_edit() and db_entry() use VNDB::Schema rather than dynamically
querying the DB. This has the minor advantage of a faster startup.
- The Elm code generator now writes to multiple files, this avoids
the namespace pollution seen in v3's Lib.Gen and makes the dependency
graph a bit more lean (i.e. faster incremental builds).
- The Elm code generator doesn't update the timestamp of files that
haven't been modified. This also speeds up incremental builds, the elm
compiler can now skip rebuilding unmodified files.
- The Elm API response generator code now uses plain functions rather
than code references and all possible responses are now defined in
Elm.pm. Turns out most API responses were used from more than a single
place, so it makes sense to have them centrally defined.
The doc page preview function is also much nicer; I'd like to apply this
to all BBCode textareas as well.
(Elm.pm itself is ugly as hell though. And we will prolly need some HTML
form generation functions in Elm to make that part less verbose)
|