Django-cotton

What's Changed
* fixed unintended literal evaluation of non dynamic properties by wrabit in https://github.com/wrabit/django-cotton/pull/113


**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v0.9.34...v0.9.35

What's Changed
* fix unhandled exception as reported in 111 and fixed with https://github.com/wrabit/django-cotton/pull/112

**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v0.9.33...v0.9.34

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:

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


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


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





* Parse template inside dynamic attributes by wrabit in https://github.com/wrabit/django-cotton/pull/110


**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v0.9.32...v0.9.33

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.

html
<!--
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:

html
{% 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 https://github.com/wrabit/django-cotton/pull/92
* Dynamic components by wrabit in https://github.com/wrabit/django-cotton/pull/73


**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v0.9.30...v0.9.32

What's Changed
* Addressed attribute order preservation in compilation for default slots as discovered in 88


**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v0.9.29...v0.9.30

What's Changed
* auto setup, refactored caching, removed lru by wrabit in https://github.com/wrabit/django-cotton/pull/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**: https://github.com/wrabit/django-cotton/compare/v0.9.28...v0.9.29