Feature comparison with django-web-components

[JuroOravec]

As I was looking for inspiration for some features, I had a look at django-slippers and django-web-components, and compared the features provided by those libraries.

Here I'm documenting django-web-components features that are either 1) significantly diffrent from django-components, or 2) could be discussed/considered for django-components.

Feature name	Description	Resolved
Fallthrough attributes	Allow to pass ad hoc key-value pairs to components as "attributes" to enable component users to configure styling and event handling. See Vue's flalthrough attributes. django-web-components takes a slightly different approach, and does not differentiate between "props" (component input) and "attrs" (extra ad hoc kwargs passed to the template. While this is mostly OK, I don't like that this approach doesn't play nicely with building of UI kit libraries (design systems). I think that the approach we discussed in #471 is a better choice, so no action here.	✅ (added in v0.74)
HTML attribute formatting	One thing is passing ad hoc attributes to components, but other is formatting them as HTML attributes. We can't expect a similar API to React and Vue for this one, as their template/AST is aware of HTML nodes (e.g. <div :class="abc">), whereas Django templating is more general and treats the underlying template as plain text. But in Python, I like the approach django-web-components took with {% attributes %} tag, which IMO can serve us as an inspiration.	✅ (added in v0.74)
Component inputs are kwargs only	Django components accept both args and kwargs. This might become relevant once discussing Typed component inputs, as that feature might require us to move towards using only kwargs for component inputs.	🟠 (no action; maybe in v2?)
Component kwargs without value are inferred as True	This would be relevant if we decided to support only kwargs. This mimicks HTML attribute behavior, where if you have e.g. <button disabled></button> then the value of disabled is set to true. Vue follows this behavior too. Don't think that React does. So {% mycomp abc=123 some_value %} would be the same as {% mycomp abc=123 some_value=True %}.	🟠 (no action; maybe in v2?)
Support both slot-ful and slot-less component tags / Configurable component tags	Recently django-components changed to support only slot-full components, so users always have to write the {% endcomponent %} in {% component "comp_name" %}{% endcomponent %}. This could be possibly revisited. django-web-components creates both the "slot-ful" and "slot-less" tag variants for each component	✅ (added in v0.90)
Shorthand component tag name	By default django-web-components component tags use the component's registered name as component tags: {% my_comp %}{% endmy_comp %} or {% #my_comp %}. Same was done in django-slippers, and de factor same is used also in React or Vue (e.g. <MyComponent />). On the other hand, django-components uses a more-verbose {% component "my_component" %} approach. However, I really like django-web-components's apprach, as it allows users to configure what tags they want to use for the components. So users could decide if they want to use {% component "my_comp" %}{% endcomponent %} or {% my_comp %}{% endmy_comp %} or something else.	✅ (added in v0.90)
Slot names are NOT variables	While we interpret slot/fill names as variables {% slot "my_slot" %}, django-web-components interprets them as plain strings {% slot my_slot %}. Since we already support variables, I don't see a need to change anything about it	🟠 (no action)
"Scoped slots" - Exposing variables through slots from component that owns the slot to the slot fill	When we have a component that defines a slot in it's template, it may be that the component precomputes some value, and would like to allow the slot fill to use that value. In Vue this is done via "Scoped slots". In React you would achieve the same by passing down a function instead of a rendered text. I was nicely surprised that django-web-components has implemented this feature too. This feature helps with organizing logic to live in those components where it is actually relevant, as opposed being lifted up to common ancestor. So IMO it is something we could consider.	✅ (added in v0.76)
Duplicate slot fills	I don't see added value in this, as you can instead insert a for loop inside the slot fill for the same effect.	🟠 (no action)
Access slots as variables in template	web-components populates a slots variables to dynamically access the slots passed to the component. This could be potentially useful for some advanced used cases. But unless people request it, it feels like a low priority.	✅ (added in v0.92)
Exposing variables through slots from slot fill to component that owns the slot	django-web-components also supports what they called "Slot attributes" it's basically like "scoped slots", but going in the opposite direction. This is an unconventional feature (not present in Vue/React), and also conceptually reverses the flow of data from parent to child. And it practically introduces another way how to pass variables to components. Overall, I don't see added value of this as these "slot attributes" could be refactored as component inputs.	🟠 (no action)
Function based components	Using functions instead of classes to define components is an interesting idea. This is akin to "Vue's render functions", or to React rendering style, where the component IS a function, and you call it with inputs, and it returns back the template fully rendered as a string. This could be useful, but low in priority, since users have an alternative approach available (using class-based components). Moreover, I think django-web-components' approach packs together 3 concepts: 1. Visual/Aesthetic - Using function instead of class, but with same functionality. Unlike us, django-web-components doesn't manage component's JS/CSS dependencies, so our Component class does more heavy lifting. So I think there's more value for us to use the class approach, so users can override individual methods and specify the CSS/JS dependencies. Altho I can imagine that "functional components" could be like a simplified alternative to the original Component class, but it doesn't really provide any new functionality, so for me low in priority. 2. Allowing to call and render a component from Python code. We could achieve something similar like MyComponent.render_from_input(args, kwargs), see row "Inlined component render" in #483) 3. Caching of inlined templates (discussed separately)	🟠 (no action, see #613)
Caching of inlined templates	django-web-components has a CachedTemplate, which caches inlined templates. I'm not sure if we cache this somehow, but it's again something we could take inspiration in	✅ (added in v0.97)
Various ways to use the register decorator	In django-web-components it can be used as @register(), @register, register(alert) @register("alert"), @register(name="alert"), register("alert", alert). On the other hand, django-components supports only @register("alert"). However, since this is just different function signature, IMO it's nice to have, and low priority unless requested.	🟠 (no action)
Specify Django's Template Library to which the components should be registered	Currently you cannot specify the instance of django.template.Library to which the components will be registered.. DWC allows to configure this. This could be useful for tests.	✅ (added in v0.88)

[JuroOravec]

Note on "Configurable component tags" - #122 is related