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

[fire]

We discussed a few things yesterday:

• uro needs a maintainer
  • I stepped up
• we need to finish this pr for review if we want to merge it into uro main
  • try to reduce generated code and code that is vendored
    • So to remove mishka
      • The login live page would need to be changed to use non-mishka UI components
      • Then the mishka stuff can all be deleted. No more generated code
  • prepare for review vs nextjs
• Discussed splitting endpoint into endpoint and endpoint_web for the two web servers.
  • 1 endpoint is a rest interface and the second endpoint is the web interface.
  • For isolation we discussed how the web endpoint must use the endpoint either via internal elixir RPC / function call or via a web REST calls
• Rebase on main
• Squash to one commit near merge
• Do quality assurance
  • Generate a list of QA tasks and check stuff still works

[fire]

• QA List
  • Login on the website
  • Login with the editor
    • Upload avatar
    • Upload world

[fire]

IMO, there’s no reason to separate the two into UI and non ui endpoints, especially if you’re using live view, since they will live on different routes already
from benbot.

I did prototype split in the uro pr.

So I need to decide if we need to proceed with two endpoints or revert to the single endpoint design

[fire]

Regarding the vendoring problem.

All @lyuma asks is we write a file saying which exact command we ran and which git version of mishka was used so we can reproduce it. We don't need to include the generator if we document which git revision we used and some steps. Doesn't even need to be a script.