Feature comparison with django-slippers #485
Replies: 2 comments 5 replies
-
|
I'm not that familiar with So you'd be able to do something like (copying the example verbatim from the essay): <html>
<body>
<div hx-target="this">
#fragment archive-ui
#if contact.archived
<button hx-patch="/contacts/${contact.id}/unarchive">Unarchive</button>
#else
<button hx-delete="/contacts/${contact.id}">Archive</button>
#end
#end
</div>
<h3>Contact</h3>
<p>${contact.email}</p>
</body>
</html>And then you can either render the full "component": Contact c = getContact();
ChillTemplates.render("/contacts/detail.html", "contact", c);Or only that "fragment": Contact c = getContact();
ChillTemplates.render("/contacts/detail.html#archive-ui", "contact", c);In |
Beta Was this translation helpful? Give feedback.
-
|
Ah, thanks for pasting the example, I think it finally clicked with me as for what the template fragments are! But I don't think so. The slipper's {% fragment as my_frag %}
<span>
abc
</span>
{% endfragment %}
<div>
{{ my_frag }}
</div>Would render <div>
<span>
abc
</span>
</div>The equivalent with django-components would be: class MyComp(component.Component):
template= """
<div>
{{ my_var }}
</div>
"""
def get_context_data(self):
my_frag = Template("""
<span>
abc
</span>
""").render()
return {"my_frag": my_frag} |
Beta Was this translation helpful? Give feedback.
-
|
Are we sure that we need feature parity? I'm a bit worried we will add features that no one using the library really wants... |
Beta Was this translation helpful? Give feedback.
-
|
Not necessarily, each of the points is up for discussion. There's a few reasons why I wrote this down:
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, agreed. I don’t think feature parity should be a goal, but it always helpful to see what others in a similar space are doing. We could eventually use it as input for one of these django-components vs. X comparison tables that people like to see when picking frameworks/libraries. |
Beta Was this translation helpful? Give feedback.
-
|
My 2 cents: I first settled on slippers for my components since it was the only available library available with django-components. At that time, I found django-components too verbose and I did not like being forced to split my component in separate files. I then discovered django-web-components and switch immediatly to it since it solved all my issues with slippers. In my opinion, even if I liked slippers at that time, there is not much to bring to django-components currently. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for feedback, I've renamed the thread to "feature comparison" so it does not imply that we necessarily want to implement all of that. Also, for the record, I made a similar comparison with django-web-components. @tissieres Agree, it was similar with me, that at first I didn't like splitting the component to multiple files and verbosity of django-components (but I wasn't aware of django-web-components, so I stayed 😄). Maybe the django-components' single file component feature should more prominent so it's clear that people don't necessarily need to split the component to files? And agree also with the assessment of Slippers, it's relatively simpler featureset, and for the features that do differ, I think that considering them in the context of |
Beta Was this translation helpful? Give feedback.
-
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-slippers features that are either 1) significantly diffrent from django-components, or 2) could be discussed/considered for django-components.
As you can see below, I marked all features as "resolved", meaning that I don't think there's much to consider here. But feel free to comment if you disagree or if I've missed something.
registry.register("my_comp", Comp). With django-component's you can do the same by importing the component classes inapps.py. Plus django-components has autodiscovery.So IMO not much to consider here.
Also implemented in django-web-components, so marking as resolved and instead consider this feature in comparison with
django-web-components.{% endcomponent %}in{% component "comp_name" %}{% endcomponent %}. This could be possibly revisited.If so, however, I suggest to see instead the implementation of django-web-components, which is more thorough, so marking as resolved and instead consider this feature in comparison with
django-web-components.{% my_comp %}{% endmy_comp %}. I like the idea because IMO it's clearer to read.But I prefer much more the approach taken by
django-web-components, where one can configure how to render the component tags. So users could decide if they want{% component "my_comp" %}{% endcomponent %}or
{% my_comp %}{% endmy_comp %}or something else. So marking as resolved and instead consider this feature in comparison with
django-web-components.django-web-components.{% var %}tagget_context_datamethod{% fragment %}tagAnd again this tag is needed in Slippers to some extend, because it misses a way to execute Python code per component.
Instead, if we need to render some component and then pass the rendered content into another component, we can do in Python, so marking this as resolved.
{% match %}tagget_context_data, so marking this as resolved.Beta Was this translation helpful? Give feedback.
All reactions