whitefusionhq / crystallized Goto Github PK

Idea from @bennypowers:

I wonder if, since it's a controller not a mixin, you could pass targets like so instead of as a static getter:

targets = new TargetsController(this, { 
  targets: {
    message: '@',
    dupMessage: '@message',
    extra: ['p.extra'],
  }
});

We could add conditional code so if an element is already defined we don't try to re-define it (maybe display a warning in the console instead)

Here's a solution someone else proposed: https://gist.github.com/fouad-j/0e19a0d9b94f50b53c87dbceca51b26c

In light of this: https://thathtml.blog/2023/07/handleevent-is-mindblowing/

We might not need to handle actions (events) in the current declarative manner that walks through the DOM, but rather tag certain elements to be referenced by event handlers at the top-level.

Since we'll no longer be an "element" but only two controllers for Lit 2, it makes sense to switch to an org and add a controllers package. Any additional Lit-related work in future can remain here in the repo and published under the @crystallized NPM org.

Any information on type safety should start with JSDoc first, not full TypeScript syntax.

I don't know why I didn't think of this before, but the addController/hostConnected API is totally framework-agnostic, and I don't believe anything in the Crystallized code is actually dependent on Lit, so I should open this up to all web components of any flavor!

Hello @jaredcwhite, first of I really love the idea behind Crystallized, I've been looking for a Stimulus alternative that would leverage native web components api and this is exactly what I had in mind! No abstractions, just simple and rich functionality that any web needs.

The only thing I dislike a little, is missing prefixes for attributes or the lack of customization for that. I personally prefer data- attributes and think it might a better aproach, and dataset property can be also leveraged this way on elements. Also I think it's more close to standards, as using custom attributes is discouraged, or at least they should be prefixed in some way.

Would you consider adding an option for prefix, similiar to https://stimulus.hotwired.dev/handbook/installing#overriding-attribute-defaults?

After implementing #8 so we're not so Lit-focused, it would make sense to allow targets and actions to function within shadow DOM as well—very nice for DSD SSR templates.

When using Ruby2JS and defining action methods with snake_case, it'd be great to be able to use those in the action attributes as well and know it'll auto-convert to camelCase.

Based on recent improvements to the Lit filter in Ruby2JS, I think I can just get rid of the LitElement subclass entirely and only offer the two controllers (DeclarativeActionsController & TargetsController). Also see #5