Publish the dev branch?

[JuroOravec]

@EmilStenstrom I'm starting to think it would be good to publish what's on the dev branch as a dev / nightly build. What do you think?

The main reason is because there's still couple more (minor to mid) breaking changes, in order for django-components to support also the django-vue project. I'd want django-components v1 to be released only once I can confirm that the django-vue project can be built on top of it, so there's no unexpected changes required after v1.

But because the amount of breaking changes is growing, I'm starting to feel like it might be good to bundle all of them into a single big release. At the same time, at the current rate, and with holidays coming up and whatnot, I think it can easily take 1-2 months to clear out my workspace.

Until that big release comes, I'm pushing all changes to dev, and I don't have that feedback loop. I cannot use the improvements I've made in my work project, and I can't test if everything's working well.

It's also harder to communicate the changes on forums / subreddits, when I can't point people to a package (even if nightly / dev).

So it'd be nice if we could publish django-components with a version like 0.1.110-dev241116 (<main version>--dev<date>) and use / test them before the actual release.

Planned changes that I have made locally, for which I yet have to make MRs:

• [non-breaking] Support accessing default and data kwargs for default fills
• [minor breaking] Definings slots / fill with variables from Component.get_context_data(). Currently slots are resolved before we obtain the data from get_context_data().
• [non-breaking] Allow to define the inlined JS / CSS in a separate file (same as we currently have Component.template and Component.template_name
• [breaking] Remove get_template() and get_template_name(), so that the template associated with each component would be static / fixed.
• [non-breaking] As a replacement for the removed get_template() and get_template_name(), introduce on_render(), a hook where users could define to dynamically change the template.
• [non-breaking / maybe minor] Add plugin support.
• [minor breaking] Remove the input validation (args, kwargs, slots). The validation would be moved into django-vue.

[EmilStenstrom]

Some questions:

• Are the changes currently on the dev branch breaking? I don't remember why you're using a separate branch...
• The only breaking (not minor breaking) change above is the removal of get_template and get_template_name. Are you sure you have to do that? Otherwise we could start merging things into django-components continuously instead?

[JuroOravec]

Yup, those changes in dev a breaking, because they change the installation steps or removes the {% component_dependencies %} tag.

I guess I'm just overly cautious, because as you'll see in #758, that one grew out of proportions, and I'm concerned the same might happen when

1. Removing get_template,
2. adding support for plugins,
3. finishing the support for JS / CSS variables, scoped CSS, etc.

These will come with more smaller breaking changes associated with those 3 features. E.g. the plugin support will also require that Component.template must be a plain string (currently I've allowed it to be str or Template), so that the plugins can modify the template as a plain string before we hand it over to Django.

---

As for the removal of get_template() and get_template_name(), that's a simplified way how I refer to a collection of changes.

Tbh I will have to revisit that one to check if it's necessary after #758 is merged. I currently have the changes related to removal of get_template() stashed away, so I can't see it, and there will be a LOT of merge conflicts when I will be un-stashing it.

But to explain, there's actually two use cases, and for both of them it seemed at the first sight that doing away with get_template() should resolve the issues:

Use case 1: Allow plugins to pre-process template as string

1. Imagine I'd want to use django-cotton syntax with django-components.

2. If I let Django to load the template first, then

   <c-button abc="xyz">
   	{{ abc }}
   </c-button>

   will be tokenized by Django as

   [
       TextNode('<c-button abc="xyz">		'),
       VariableNode('abc'),
       TextNode('	</c-button>'),
   ]

3. So if I am a plugin that translates django-cotton syntax into django-components, I will have to go over all the nodes and correct them, so I would end up with:

   [
       ComponentNode(name='button', abc="xyz", content=[
           VariableNode('abc'),
       ]),
   ]

4. But that means that the plugin would have to interact with the internals of django-components. E.g. it would need to know how to construct the ComponentNode.

5. So instead, the plugin may decide to take the simpler route, and translate only the raw template string. So it needs to translate

   <c-button abc="xyz">
   	{{ abc }}
   </c-button>

   into

   {% component "button" abc="xyz" %}
   	{{ abc }}
   {% endcomponent %}

   The upside is that the plugin will be using only the public API of django-components.

6. BUT, it plugin takes the path described in step 5, there's issues with that:

   • The plugin might need to re-parse the component's template. If the component's template is defined as a string, all is fine. But if it's defined as a Template instance, then the content would have been already automatically parsed by Django. So the plugin would have to access the raw contant under (I think) Template.content, process the content, and let Django parse it the second time. So it's not the most efficient approach.

   • Moreover, if we allow Django to first automatically parse the template, then plugins would still be limited. E.g. they would not be able to add syntax that the Django's parser would deem invalid.

     This is similar to how we handle the default or required flags on the {% slot %} tag. We actually extract those flags BEFORE passing it to Django to parse the rest of the kwargs. Because to Django, something like this {% slot name="abc" required %} means "'required' is a positional argument", and will raise because "a positional argument is after a keyword argument".

7. The solution to issues in step 6 is to allow plugins to pre-process the template as a raw string, before we pass it to Django parser.

8. However, there is the Component.get_template(), which may return a Template instance, which means that the template string would be already parsed by Django. Minimal fix would be to allow to use / return only raw string from Component.get_template() and Component.template.

9. An alternative solution could be to allow get_template() to return Template instance, but in that case the plugins would NOT be able to pre-process the template string. So it would be the responsibility of the users who use such plugins to make sure that if they use get_template() / template, that they do not return a Template instance, but only a plain string.

   Potentially the responsibility could lie with the plugins too. If a plugin would somehow keep track of whether a template WAS / WAS NOT preprocessed by the plugin (e.g. by inserting a {# ... #} comment), then the plugin could raise an error if it came across a Template instance whose string content was NOT preprocessed.

Use case 2: Allow to access Component.is_filled in get_context_data

NOTE: I will have to reevaluate this one after #758

1. So for the (Vuetify) component library, I need to pass from Django to Alpine the info about which slots were filled.

2. My initial approach was to use the Component.is_filled dictionary, e.g.:

   class MyTable(Component):
       def get_context_data(self. *args, **kwargs):
           return {
               "slots": self.is_filled,
           }

3. BUT this caused a chicken-and-egg problem:

   1. I tried to access Component.is_fillled from within Component.get_context_data()
   2. To populate is_filled, I need to read the component's Template.
   3. But we have get_template() which accepts the current context, whereas the context also contains the data from get_context_data()

4. So to resolve this situation, I was thinking of making the component's template static (removing get_template()), or at least changing the internal order of execution, so get_template() would be executed before get_context_data().

5. BUUUT if I consider the changes in feat: passthrough slots and more #758, then it's clear to me that I do not need to use is_filled. I can get away with passing just Component.input.slots from Django to Alpine. Because I just need to pass the info about which slots WERE filled, and this automatically implies that any other slots were NOT filled.

   So that means that I do not need to access is_filled from within get_context_data(). And so I think I should be able to get away with still keeping get_template() as it is.

[JuroOravec]

Hm, with a bit of time to think after I wrote the previous comment, I'm more OK with merging what's currently in the dev* into master. It won't be ideal, because there's a chance that there will be another round of breaking changes later on. But the world is not ideal, and it's better to release this than wait 1-2 months.

* After #758 and #752 are merged

[EmilStenstrom]

I see what you mean. I think breaking things now is better than breaking things later. I would expect fewer breakages over time, so delaying them like we do with the dev branch doesn’t feel right. It’s like with a product, get it out in front of people as soon as possible.