LiveView rewrite

[benbot]

Rewriting the frontend in live_view and fixing little things I find along the way.

[lyuma]

I am not very excited about vendoring the entirety of the UI code from https://github.com/mishka-group/mishka_chelekom - plus, it makes it hard to review. Why can't we include it as a dependency like we do for the rest of the elixir packages.
If we have to make changes to it, perhaps we should fork the mishka_chelekom components and then reference that fork.
Finally, if we do decide to vendor that LiveView addon, we need to add proper attribution and a copy of the Apache 2.0 license to the Uro code so people know where it came from.

Finally, more broadly about the proposal to use LiveView itself...

Depending on the scope and complexity of this change, I would like to suggest we create a new branch. iFire will complain about having multiple branches, but I won't approve merging this to master while we have two half-complete rewrites. A second branch for liveview is the best we can do until the members of the V-Sekai community can agree on what framework to use for the frontend code. I would be happy to deploy this branch to another subdomain of v-sekai.org

Basically, let's try it out in a branch. If this rewrite works well and the overall community prefers LiveView over Next.js, then we can eventually merge it to master. I just don't want to go through the process of pushing unmaintained code to master a second time in one year, so I want to know it will be functional and well-maintained.

[benbot]

@lyuma its the way the mishka component library is distributed. Its for customizability.

it generates the components (not technically vendoring) and updates them when the cli is run (via sourcery, so it never breaks components)

Idk if we even need Apache attribution in this case as the mishka repo generates these components when run, but it couldn’t hurt.

we don’t need to use mishka (daisyui is also fine. Mishka just has built in support for some live_view features, but nothing that can’t be built by hand) and we don’t need to vendor every component all at once. I just did for this PR.

that being said, all the mishka components are added in a single commit and they’re all in their own directory, so it shouldn’t add any review burden. Just ignore the mishka files as I’ve made no custom changes to them

as far as deployment goes, yes that was my plan.
I was going to have login and the backpack UI built first, then we could evaluate.

if it seems good, I’ll migrate over more of the pages (there doesn’t seem like too much)

then we could decide finally.

regardless there are some important configuration and dockerfile updates in this PR (I’ve talked with @dragonhunt02 about a little bit) that I’ll split out into another if we don’t end up wanting to merge all this in.

[benbot]

For context: https://mishka.tools/chelekom/docs

You only add what you need to the project, and in the production environment, there will be no trace of the Chelekom library. Instead, all components will be placed in your Phoenix project's components path.

so there’s no production dependencies on mishka either. We don’t distribute any of their code. Just the code their code generates.

I have no intention on dying on the mishka hill, so if you really don’t like it, I’ll just use something else.

[fire]

A second branch for liveview is the best we can do until the members of the V-Sekai community can agree on what framework to use for the frontend code. I would be happy to deploy this branch to another subdomain of v-sekai.org

How do we implement this?

[benbot]

A quick n dirty way would be to add a multi stage dockerfile to main which would pull down this live view branch, build it, and run it. Add that to the docker compose

Then add an entry into the master branch Caddy file to forward requests with the host name beta.v-sekai.org to the new container.

[dragonhunt02]

A quick n dirty way would be to add a multi stage dockerfile to main which would pull down this live view branch, build it, and run it. Add that to the docker compose

Then add an entry into the master branch Caddy file to forward requests with the host name beta.v-sekai.org to the new container.

Docker compose and Caddyfile are used for local development.
Production server runs on kubernetes, see configs here https://github.com/V-Sekai/flux-config/tree/flux2/workloads
I don't know how server image build automation is set up though