v0.9.34

What's Changed

• fix unhandled exception as reported in #111 and fixed with #112

Full Changelog: v0.9.33...v0.9.34

v0.9.33

Dynamic Attributes now are parsed for template strings too

Following from the issue #100, cotton now parses any dhango template used in dynamic attributes, before the evaluation step. This allows us to do things like:

<c-slider :images="['{{ image1 }}', '{{ image2 }}']" />
<!-- provides list of images in the component -->

<c-map :location="{
  'longitude': {{ longitude }},
  'latitude': {{ latitude }}
}" />
<!-- provides dict in the component -->

<c-graph :data="{ 'series': {% get_graph_data %} }" />
<!-- provides dict in the component -->

• Parse template inside dynamic attributes by @wrabit in #110

Full Changelog: v0.9.32...v0.9.33

v0.9.32

What's Changed

Dynamic Components

Sometimes there is a need to include a component dynamically, for example, you are looping through some data and the type of component is defined within a variable.

<!--
form_fields = [
  {'type': 'text'},
  {'type': 'textarea'},
  {'type': 'checkbox'}  
]
-->

{% for field in form_fields %}
    <c-component :is="field.type" />
{% endfor %}

You can also provide a template expression, should the component be inside a subdirectory or have a prefix:

{% for field in form_fields %}
    <!-- subfolder -->
    <c-component is="form-fields.{{ field.type }}" />

    <!-- component prefix -->
    <c-component is="field_{{ field.type }}" />
{% endfor %}

• Fixed auto-setup where no builtins key present by @wrabit in #92
• Dynamic components by @wrabit in #73

Full Changelog: v0.9.30...v0.9.32

v0.9.30

What's Changed

• Addressed attribute order preservation in compilation for default slots as discovered in #88

Full Changelog: v0.9.29...v0.9.30

v0.9.29

What's Changed

• auto setup, refactored caching, removed lru by @wrabit in #8

Auto configuration

Inspired by Carlton's package "Template Partials", the package now attempts auto-configures your settings.py by default.

Migration guide

• If you previously modified your loaders and added cotton's loader, you can now remove the loader key altogether.
• Additionally if you want to cleanup more, you can remove django_cotton.templatetags.cotton from builtins.

You can of course leave them there if you prefer.

If you alternatively need to define custom loaders then reach for using django_cotton.apps.SimpleAppConfig in INSTALLED_APPS instead and this will allow you define the builtin django_cotton.templatetags.cotton and loader django_cotton.cotton_loader.Loader as you need. If manually configuring, it's advised you wrap Cotton's loader in the Django cached loader for minor optimal performance

Possible breaking change ⚠️

Because this changes the default behaviour, there may well be some edge cases if you have already got a custom loader definition so please test this before deploying to any production environments.

Full Changelog: v0.9.28...v0.9.29

v0.9.28

What's Changed

• Revert "Fix dev cache" by @wrabit in #86

Full Changelog: v0.9.27...v0.9.28

v0.9.27

What's Changed

• Fix dev cache by @wrabit in #84
• related: #83

Full Changelog: v0.9.26...v0.9.27

v0.9.26

What's Changed

• Check for the presence of cotton tags before parsing which prevents unnecessary processing by @wrabit in #80

Full Changelog: v0.9.25...v0.9.26

v0.9.25

What's Changed

• Fix case sensitive placeholder issue in connection with duplicate attribute handling mechanism by @wrabit in #79

Full Changelog: v0.9.24...v0.9.25

v0.9.24

What's Changed

• Preserve spaces around tpl expressions by @wrabit in #78
• Introduces an internal cache versioning system so if a release would break cached and compiled versions, we can force the rebuild

Full Changelog: v0.9.23...v0.9.24