cami.js VS select2

Preact requires a build step otherwise you don't get JSX and you have to build applications a la mithril.js mode:

> const app = h('h1', null, 'Hello World!');

With Web Components no build step is required and you're still able to build JSX'ish code. See the code below this section: https://github.com/kennyfrc/cami.js#key-concepts--api

Yes, the lib's great!

Unfortunately I haven't thought much yet about interoperability with other web components libraries like lit. I imagined folks would choose just one web component library over the other.

That said, you can initialize reactive properties(1), but property bindings won't work if there's a parent LitElement (as my reactive properties need to be called with either a .value method or an .update method for getting and setting respectively).

As of the moment, what's possible is interop with other cami elements using a store, and in a future version, i'm considering a richer event system for external javascript code to listen to.

---

(1) Initializing is possible with observerableAttr: https://github.com/kennyfrc/cami.js/blob/master/examples/008...

The author is getting a bit of heat, and I think rightfully so. Here is the "tool" he's all bragging about: https://github.com/kennyfrc/cami.js/blob/master/src/cami.js

The whole thing is 250 Loc half of which is comments. And not to discount on that (Redux itself is not that big, though the ecosystem is). But this tool/project could be just a few blog posts where the author explains the patterns/libraries he is using.

It also doesn't help that his blog post/tool has the highest concentration of buzzword language you can expect. Please don't do that.

Most people using react aren't building SPAs. Vue/React can be used the same way as jquery, which is to add enhanced UI functionality that server-side HTML views simply can't offer.

The best example is a multi-select box, or a searchable select box with autocomplete (what W3 calls the combobox pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) which in jquery was usually via https://select2.org/

For example, on my company website there's a timezone select box with are 151 options. Asking a user to simply scroll through 100+ to find theirs is annoying vs typing a few characters and hitting enter.

There's many examples of select boxes like that and there really is no static server-side way to solve this problem (I tried hard to think of one)... without creating a multi-page Wizard for what should be a single field on a larger form.

If you're building a SaaS product there are many highly-interactive components that demand JS and there's really no better mainstream solution atm than static-first sites with small "islands" of Vue/React style components (ideally with hydration) where interactivity is required.

People still abuse React/Vue of course, but the trend is 100% moving back to "mostly static" rather than slow SPAs and IMO JS-powered components are not never going away unless browsers start offering these complex components built-in.

I’m a fan of select2 (https://select2.org), it supports loading in data from a foreign source (API)

You could use a Select2() for the records which prevent the massive amount of data being transferred.

Sometimes I still import it for only one thing : select2 that depends on it. Does anyone have an alternative ? I'd love it

The traditional solution was to use ModelAdmin.raw_id_fields, a comma-delimited string of IDs in a text input. Many users found the interaction inelegant, and so ModelAdmin.autocomplete_fields with live search integration with Select2 was added in Django 2.0.

The module django-extensions has a searchable select box widget. There are others using Select2 as well.