[2.x] Replace the current UI with VueJS Client UI

@JFeltkamp: Any updates or plans here?

Could we open-source the vue code directly in the module instead of a separate repository?

> Could we open-source the vue code directly in the module instead of a separate repository?

My idea was, to left the JS library an independent tool, that can be used with any type of backend, not just Drupal.
Why do you think, this step could make sense.

Yes of course we can also do that. If it was just for this module I would have put it in here to make things less complicate and more compact.

One disadvantage we experienced in the current, separate repository is that it's not open source and you're the only maintainer, so if you're busy, the other maintainers can't help that much. That would be the more important point to me.

And of course, this is all your decision :)
We're still wtih Vue btw. also Svelte would be okay, if you should have switched. Should it have a similar API to the current react implementation or would you do a lot things different?

Writing this, I remember another point that we should solve differently for 2.x and the library. Config translation isn't used as it's supposed to be, if I remember correctly. But we will find a solution for that anyway, if placed here or separately!

Yes OK I understand. You are absolutly right, that it is a problem that I'm th only maintainer.
So I will give you full access to all repos on GitHub.

Thanks @JFeltkamp! Funny I didn't even see this repo exists. Whao, you already wrote a lot of code!

We're very busy currently, but if you'd be interested, we could plan a sprint on Cookies 2.x and the Vue Client next year Q1 / Q2 eventually?
I think it would make sense then to simply talk then via web meeting. Until then we should review the various issues and make a plan as far as possible?

This is @Grevil: https://github.com/joshsedl

How would you want to proceed?

Update: Based on the core HTMX discussion ( 🌱 Gradually replace Drupal's AJAX system with HTMX Active ), we may instead use HTMX instead of Vue?

We'd then need a dependency on https://www.drupal.org/project/htmx →

@Anybody: I respect but don't understand the idea and intention, why to use HTMX here. That would be a very major overhaul of the entire system. HTMX intends to generate the entire markup in the backend and is not supporting APIs. Then we will need additional Javascript to map the frontend dynamics, instead of (as it is now with Vue or React) directly controlling its own markup and event management as a really autonomous frontend component with the full service. Instead of Vue you would then have HTMX as a dependency, which means no independence is gained. - My opinion to that: I don't think this is the right way. I don't agree.

Because I think, that HTMX is NOT an innovative concept, and has some really ugly pitfals in consequence: I would also recommend this article by heise online: https://www.heise.de/blog/HTMX-Die-perfekte-UI-Technologie-9633960.html

But I'm still open for arguments: What exactly are the problematic Issues? Why do you think HTMX is a good idea? Or maybe I would be convinced by a prototype that shows that all concepts can be implemented well.

@JFeltkamp thank you for your feedback and sorry I didn't leave more information here.
The key discussion points are the following:

• Might be just good enough to solve what COOKiES needs for frontend, combined with regular Drupal JS
• No separate client app and no build step (direct integration into the module) without additional workflows
• Possible integration into Core one day

But this was just meant as note / reminder to think about, far away from being a plan or active development :)
I didn't use HTMX myself yet, my intention was to mention it here, before we proceed with the Vue client.

I don't think HTMX would help to solve any of this module's issues. For me, the main issues with CookiesJSR are (in order of significance)

-) The CC-ND licence of CookiesJSR. The VueJS variant also is CC-ND licenced. AFAIK I'm not even allowed to ship a patched version of CookiesJSR to my clients. This is a huge problem. So far I could work around patching CookiesJSR's source with "creative" CSS and JS, but for me any code using the CC-ND licence is a problem that needs to be replaced.

-) The jQuery dependency. In our newer v10 projects, Cookies is the only module left still using jQuery. This is a huge footprint just for cookie management. Rewriting the interactions between Drupal/the module and the client component to Vanilla JS would be a much larger performance boost for us, than switchting from React to Vue or whatever JS framework of the day.

Imagine a big gap here :-)

-) The external app / the external build step. To me CookiesJSR is something similar to a carousel JS lib like SplideJS: It is a quite isolated component with a lot of state and logic that needs to run on the client, and not on the server. So I think one externally build JS file is an acceptable tradeoff here.
E.g. I also had to patch SplideJS for my specific needs, but the build step is outsourced into a separate project, and multiple Drupal projects simply pull my patched SplideJS Git tag in composer.json. No NodeJS / extra built step required inside the Drupal project, the Drupal projects are still built- and deployable on any cheap vanilla PHP host. Could imagine doing the same with CookiesJSR.

HTMX primarly helps with client-server-interaction. Cookies just needs an initial initialization/config from the server, and then fully runs inside the client. IMHO this is a good architecture for this use-case, I don't want a server roundtrip after activating a service (group), it should run in the client. So I believe, even when core would switch to HTML, it would not change that much at all for this module. (Actually it should not change anything at all for this module, because we should use only Vanilla JS for interactions Drupal <==> client JS component).

Beside license, maintenance status and technology, I just found another reason why the old cookiesjsr should really leave us: 📌 JS Performance & size optimization (cookiesjsr) Active
The JS size is really large and by far one of the largest assets loaded in several projects. I'm not sure which of the points mentioned there is worst. ;D

But someone needs to find the time to finish this...

Cancelled in favor of 📌 [2.x] Rewrite in Twig templates & Vanilla JS / TS Active .