Django-cotton

Latest version: v2.0.1

Safety actively analyzes 722491 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 11

31.83

---

Block and Extends (Django equivalent)


Django average: 9.38 ms



- Cotton before: 11.38 ms
- Cotton after: 10.56 ms

7.21

---

Include


Django average: 3.12 ms



- Cotton before: 3.16 ms
- Cotton after: 3.04 ms


✅ Cotton performs on-par with Django when used as partial inclusion.

---

⚠️ Possible breaking changes:

- Boolean attributes were previously triggered even when an attribute had an intentional empty srtring:

html
<c-comp myattr />
<c-comp myattr="" />
<c-comp :myattr="i_evaluate_as_empty_string" />

{{ myattr }} <!-- All cases above parse as True


This has now been fixed and only valueless attributes will render as True. Although this was unintentional, some of you may have relied on this defunct behaviour, so be sure to test.


* Support quoted json-like values in {{ attrs }} by mattbha in https://github.com/wrabit/django-cotton/pull/137
* updated render benchmarks by wrabit in https://github.com/wrabit/django-cotton/pull/138
* Support proper boolean attributes by wrabit in https://github.com/wrabit/django-cotton/pull/139
* Tags rewrite + optimisations (up to 28% faster) by wrabit in


**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v0.9.40...v1.0.0

2.0.1

Changed default behaviour of context isolation to non-isolated

- The last release creates an undesirable effect where context processors are re-generated on each component render ([issue](269 )) which in some cases can have negative side effects depending on how you are using them. For the time being it's safer to revert the default behaviour until the issue can be thoroughly looked into and resolved.

* turned off context isolation by default by wrabit in https://github.com/wrabit/django-cotton/pull/270

**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v2.0.0...2.0.1

2.0.0

Component context isolation by default

**Although this doesn't bring much in terms of new functionality, there is a risk of it being a breaking change due to the change in default behaviour so thorough testing of this version in your project is highly recommended before deploying it to production.**

Explanation

Currently, variables defined in a parent view or component are implicitly made available to all child components whether you have passed them as attributes or not.

This can result in data unintentionally leaking across components sometimes leading to hard-to-trace side effects.

An example of the problem:

Imagine a variable `title` that has been made available to a component or view template called `parent.html`.

html
<!-- parent.html -->
{{ title }}
<c-child />


The child component also uses a variable named `title`:

html
<!-- child.html -->
{{ title }}


Before this release, parent's `title` is automatically made available to the child component. If it's intended that the child should have its own unique title, it becomes very easy to miss if we have forgotten to provide a title to child as it would use the title from parent context.

From now on `title` from the parent would not be available in the child - it should be passed explicitly as an attribute, like:

html
<!-- parent.html -->
<c-child title="{{ child_title }}" />


Summarising benefits of this approach:

- Missing variables will be more obvious to spot in development as context from other views and components cannot interfere.
- Defining attributes keeps data dependencies well defined making it clear to see what data components rely on, making jobs like refactoring and understanding easier.

Context processor context stays

Keeping a balance between component isolation whilst keeping some of the automatic benefits of Django Templates, data from any enabled context processor (builtin or custom) will remain available. (i.e. `{{ user }}`, `{{ request }}`, `{{ messages }}`, `{{ perms }}`)

1.6.0

Create default component with index.html

We've introduced the ability to choose a default component when calling a directory path by using an index.html.

[Docs](https://django-cotton.com/docs/usage-patterns#index)

Before:


- cotton
- card
- header.html
- card.html


<c-card.card>
<c-card.header />
</c-card.card>


After:


- cotton
- card
- header.html
- index.html


<c-card>
<c-card.header />
</c-card>


* Added index.html pattern by wrabit in https://github.com/wrabit/django-cotton/pull/256
* added docs for index.html pattern by wrabit in https://github.com/wrabit/django-cotton/pull/257


**Full Changelog**: https://github.com/wrabit/django-cotton/compare/1.5.3...1.6.0

1.5.3

Fix non-dynamic attributes on cvars

* Fixes parsing of non-dynamic attributes in cvars by wrabit in https://github.com/wrabit/django-cotton/pull/251

Previously we were still template-parsing non-dynamic attributes on `<c-vars />`. So this:

`<c-vars attribute1="None" attribute2="False" attribute3="1" />`

Would give us the python types `None`, `False`, `1` respectively. Even though if these were attributes on the component, they would have correctly been provided as strings. As raised in 249.

**Full Changelog**: https://github.com/wrabit/django-cotton/compare/v1.5.2...1.5.3

Page 1 of 11

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.