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.

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

The child component also uses a variable named title:

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

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

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 #256
• added docs for index.html pattern by @wrabit in #257

Full Changelog: 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 #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: v1.5.2...1.5.3

v1.5.2

Allow valid json to be passed inside attributes

• Handle attributes containing quoted spaces by @wrabit in #241

Previously, passing a space inside a quoted string inside an attribute value would produce a malformed string due to the way Django understands attributes on a templatetag. Cotton's underlying component templatetag now handles this as expected.

In reference to:

• #240

Full Changelog: v1.5.1...v1.5.2

v1.5.1

COTTON_BASE_DIR to set project base location

• Don't rely on existence of BASE_DIR settings variable. by @fbinz in #234

New Contributors

• @fbinz made their first contribution in #234

Full Changelog: v1.5.0...v1.5.1

v1.5.0

Support shorthand alpine.js x-bind with ::

• Support colon escaping - alpinejs bind shortcut support by @wrabit in #227
• More here: https://django-cotton.com/docs/components#alpine-js-support
• Related discussion #180

Full Changelog: v1.4.0...v1.5.0

v1.4.0

Support for top-level project root templates

If you are a top-level templates person, you can now place your cotton components in the project root folder. Both of these approaches are supported:

• [project]/templates/cotton/... (NEW)
• [project]/[app]/templates/cotton/...

Full Changelog: v1.3.0...v1.4.0

v1.3.0

Support hyphenated filenames

• added support for hyphenated component filenames by @wrabit in #214

This introduces a new config option as detailed in the docs: https://django-cotton.com/docs/configuration.

Summary

<c-my-button />

Filepath before: cotton/my_button.html

Filepath after: cotton/my-button.html
(with COTTON_SNAKE_CASED_NAMES = False)

What else

• raise value error when multiple c-vars provided by @wrabit in #213

Cotton only supports a maximum of 1 c-vars tag per component. Some user's reach for using multiple, which is not currently supported. To ensure this is clear, cotton now raises an exception when it detects more than one c-vars in a component.

Full Changelog: v1.2.1...v1.3.0

v1.2.1

What's Changed

• Fixes direct rendering components that use cvars, referenced in #201, by @wrabit in #202

Full Changelog: v1.2.0...v1.2.1

v1.2.0

What's Changed

• Supports dynamic components with only context isolation by @wrabit in #197

Full Changelog: v1.1.3...v1.2.0