-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server-side UI #14
Merged
Merged
Server-side UI #14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This might be nice - it allows us to generate the openapi client ~internally, the types could line up, and generally dioxus seems really neat. Let's see how it handles
This allows "cargo run" to pick it up without any extra args.
This doesn't work, because our pagination arg is ... not understood? What.
Several openapi tools can't deal with "explode"'d structure Query args, I'm now learning. This allows progenitor to generate a syntactically-correct rust client, and fixes the redocly apidoc site, too.
Impressive how easy that is!? Actually neat. Now, unfortunately progenitor doesn't generate structs that are PartialEq, so I can't define components for them yet.
* Introduce the "dev" feature flag to lz-cli and lz-web, which pulls in the crates necessary to do progenitor codegen. * Use that to codegen the lz-openapi client. * Use that in lz-ui to define components that take the lz-openapi types.
One file per component, seems pretty tidy
This allows specifying deps between the frontend and the backend, and healthchecks too.
This should work much better now that things happen via the URL query in the API, and be more extensible too.
* Don't use path parameters anymore - the generated openapi client can not do query string parameters. Instead, use the JSON body * Directly use the search criteria enum as a vector of search crits.
Anytime I add a tag to the search, it should start loading a different set of data. But it doesn't. Apparently, coroutines are just ... around? WHY.
I'm losing my mind with dioxus, and I think this rewrite is basically non-salvageable. That it's this difficult to tell what is going on is a strong indicator to me that it's not ready for serious (or even hobbyist, by-me) usage, at least now; but maybe never will be. Maybe reactive programming just isn't for me?! Who knows.
Seriously, why did I ever doubt this
As djc/askama#996 highlights, call blocks have a different syntax in django templates.
The process-compose runner is so buggy, it's ridiculous. proc-flake/honcho seems much more stable.
This is hilarious, but it works pretty decently... and isn't hostile to people opening new tabs!
Fewer things to duplicate, looks neater and it's shorter too.
This should cut down on the amount of cloning (only unsightly, probably not performance-relevant) we have to do.
This looks awful, but it works pretty ~decently? It's absolutely unstyled, but works just about the way I want it to and it's real fast.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So this is a biiiiig PR. It started out as an attempt to rebuild the frontend with dioxus, which failed spectacularly after 4 days:
So, basically the ~same downsides as react+typescript with one minor benefit. I'm almost convinced that functional-reactive programming is great for other people, but definitely isn't for me.
Building a server-templated web app with askama took me 2 hours, and it can load bookmarks, with "infinite scrolling"/cursored load-more behavior. Imagine that.
In addition, this implements bookmark editing on the webface.