diff --git a/dev/404.html b/dev/404.html index 9cc18828..8c511f3a 100644 --- a/dev/404.html +++ b/dev/404.html @@ -1 +1 @@ - Django-Components

404 - Not found

\ No newline at end of file + Django-Components

404 - Not found

\ No newline at end of file diff --git a/dev/SUMMARY/index.html b/dev/SUMMARY/index.html index 399ad0f5..413297fd 100644 --- a/dev/SUMMARY/index.html +++ b/dev/SUMMARY/index.html @@ -1 +1 @@ - SUMMARY - Django-Components
\ No newline at end of file + SUMMARY - Django-Components
\ No newline at end of file diff --git a/dev/concepts/advanced/authoring_component_libraries/index.html b/dev/concepts/advanced/authoring_component_libraries/index.html index 89d9b2fc..35cd1b05 100644 --- a/dev/concepts/advanced/authoring_component_libraries/index.html +++ b/dev/concepts/advanced/authoring_component_libraries/index.html @@ -1,4 +1,4 @@ - Authoring component libraries - Django-Components
Skip to content

Authoring component libraries

You can publish and share your components for others to use. Here are the steps to do so:

Writing component librariesΒ€

  1. Create a Django project with a similar structure:

    project/
    + Authoring component libraries - Django-Components      

    Authoring component libraries

    You can publish and share your components for others to use. Here are the steps to do so:

    Writing component librariesΒ€

    1. Create a Django project with a similar structure:

      project/
         |--  myapp/
           |--  __init__.py
           |--  apps.py
      diff --git a/dev/concepts/advanced/component_registry/index.html b/dev/concepts/advanced/component_registry/index.html
      index ced5cf08..06a93768 100644
      --- a/dev/concepts/advanced/component_registry/index.html
      +++ b/dev/concepts/advanced/component_registry/index.html
      @@ -1,4 +1,4 @@
      - Registering components - Django-Components      

      Registering components

      In previous examples you could repeatedly see us using @register() to "register" the components. In this section we dive deeper into what it actually means and how you can manage (add or remove) components.

      As a reminder, we may have a component like this:

      from django_components import Component, register
      + Registering components - Django-Components      

      Registering components

      In previous examples you could repeatedly see us using @register() to "register" the components. In this section we dive deeper into what it actually means and how you can manage (add or remove) components.

      As a reminder, we may have a component like this:

      from django_components import Component, register
       
       @register("calendar")
       class Calendar(Component):
      diff --git a/dev/concepts/advanced/hooks/index.html b/dev/concepts/advanced/hooks/index.html
      index 5bb0ea89..b57b35b5 100644
      --- a/dev/concepts/advanced/hooks/index.html
      +++ b/dev/concepts/advanced/hooks/index.html
      @@ -1,4 +1,4 @@
      - Lifecycle hooks - Django-Components      

      Lifecycle hooks

      New in version 0.96

      Component hooks are functions that allow you to intercept the rendering process at specific positions.

      Available hooksΒ€

      • on_render_before
      def on_render_before(
      + Lifecycle hooks - Django-Components      

      Lifecycle hooks

      New in version 0.96

      Component hooks are functions that allow you to intercept the rendering process at specific positions.

      Available hooksΒ€

      • on_render_before
      def on_render_before(
           self: Component,
           context: Context,
           template: Template
      diff --git a/dev/concepts/advanced/html_tragments/index.html b/dev/concepts/advanced/html_tragments/index.html
      index fefdfe78..f2d58495 100644
      --- a/dev/concepts/advanced/html_tragments/index.html
      +++ b/dev/concepts/advanced/html_tragments/index.html
      @@ -1,4 +1,4 @@
      - HTML fragments - Django-Components      

      HTML fragments

      Django-components provides a seamless integration with HTML fragments (HTML over the wire), whether you're using HTMX, AlpineJS, or vanilla JavaScript.

      When you define a component that has extra JS or CSS, and you use django-components to render the fragment, django-components will:

      • Automatically load the associated JS and CSS
      • Ensure that JS is loaded and executed only once even if the fragment is inserted multiple times

      Info

      What are HTML fragments and "HTML over the wire"?

      It is one of the methods for updating the state in the browser UI upon user interaction.

      How it works is that:

      1. User makes an action - clicks a button or submits a form
      2. The action causes a request to be made from the client to the server.
      3. Server processes the request (e.g. form submission), and responds with HTML of some part of the UI (e.g. a new entry in a table).
      4. A library like HTMX, AlpineJS, or custom function inserts the new HTML into the correct place.

      Document and fragment typesΒ€

      Components support two modes of rendering - As a "document" or as a "fragment".

      What's the difference?

      Document modeΒ€

      Document mode assumes that the rendered components will be embedded into the HTML of the initial page load. This means that:

      • The JS and CSS is embedded into the HTML as <script> and <style> tags (see JS and CSS output locations)
      • Django-components injects a JS script for managing JS and CSS assets

      A component is rendered as a "document" when:

      Example:

      MyTable.render(
      + HTML fragments - Django-Components      

      HTML fragments

      Django-components provides a seamless integration with HTML fragments (HTML over the wire), whether you're using HTMX, AlpineJS, or vanilla JavaScript.

      When you define a component that has extra JS or CSS, and you use django-components to render the fragment, django-components will:

      • Automatically load the associated JS and CSS
      • Ensure that JS is loaded and executed only once even if the fragment is inserted multiple times

      Info

      What are HTML fragments and "HTML over the wire"?

      It is one of the methods for updating the state in the browser UI upon user interaction.

      How it works is that:

      1. User makes an action - clicks a button or submits a form
      2. The action causes a request to be made from the client to the server.
      3. Server processes the request (e.g. form submission), and responds with HTML of some part of the UI (e.g. a new entry in a table).
      4. A library like HTMX, AlpineJS, or custom function inserts the new HTML into the correct place.

      Document and fragment typesΒ€

      Components support two modes of rendering - As a "document" or as a "fragment".

      What's the difference?

      Document modeΒ€

      Document mode assumes that the rendered components will be embedded into the HTML of the initial page load. This means that:

      • The JS and CSS is embedded into the HTML as <script> and <style> tags (see JS and CSS output locations)
      • Django-components injects a JS script for managing JS and CSS assets

      A component is rendered as a "document" when:

      Example:

      MyTable.render(
           kwargs={...},
       )
       
      diff --git a/dev/concepts/advanced/provide_inject/index.html b/dev/concepts/advanced/provide_inject/index.html
      index 5065f30d..af282edb 100644
      --- a/dev/concepts/advanced/provide_inject/index.html
      +++ b/dev/concepts/advanced/provide_inject/index.html
      @@ -1,4 +1,4 @@
      - Prop drilling and provide / inject - Django-Components      

      Prop drilling and provide / inject

      New in version 0.80:

      Django components supports the provide / inject or ContextProvider pattern with the combination of:

      1. {% provide %} tag
      2. inject() method of the Component class

      What is "prop drilling"?Β€

      Prop drilling refers to a scenario in UI development where you need to pass data through many layers of a component tree to reach the nested components that actually need the data.

      Normally, you'd use props to send data from a parent component to its children. However, this straightforward method becomes cumbersome and inefficient if the data has to travel through many levels or if several components scattered at different depths all need the same piece of information.

      This results in a situation where the intermediate components, which don't need the data for their own functioning, end up having to manage and pass along these props. This clutters the component tree and makes the code verbose and harder to manage.

      A neat solution to avoid prop drilling is using the "provide and inject" technique.

      With provide / inject, a parent component acts like a data hub for all its descendants. This setup allows any component, no matter how deeply nested it is, to access the required data directly from this centralized provider without having to messily pass props down the chain. This approach significantly cleans up the code and makes it easier to maintain.

      This feature is inspired by Vue's Provide / Inject and React's Context / useContext.

      How to use provide / injectΒ€

      As the name suggest, using provide / inject consists of 2 steps

      1. Providing data
      2. Injecting provided data

      For examples of advanced uses of provide / inject, see this discussion.

      Using {% provide %} tagΒ€

      First we use the {% provide %} tag to define the data we want to "provide" (make available).

      {% provide "my_data" key="hi" another=123 %}
      + Prop drilling and provide / inject - Django-Components      

      Prop drilling and provide / inject

      New in version 0.80:

      Django components supports the provide / inject or ContextProvider pattern with the combination of:

      1. {% provide %} tag
      2. inject() method of the Component class

      What is "prop drilling"?Β€

      Prop drilling refers to a scenario in UI development where you need to pass data through many layers of a component tree to reach the nested components that actually need the data.

      Normally, you'd use props to send data from a parent component to its children. However, this straightforward method becomes cumbersome and inefficient if the data has to travel through many levels or if several components scattered at different depths all need the same piece of information.

      This results in a situation where the intermediate components, which don't need the data for their own functioning, end up having to manage and pass along these props. This clutters the component tree and makes the code verbose and harder to manage.

      A neat solution to avoid prop drilling is using the "provide and inject" technique.

      With provide / inject, a parent component acts like a data hub for all its descendants. This setup allows any component, no matter how deeply nested it is, to access the required data directly from this centralized provider without having to messily pass props down the chain. This approach significantly cleans up the code and makes it easier to maintain.

      This feature is inspired by Vue's Provide / Inject and React's Context / useContext.

      How to use provide / injectΒ€

      As the name suggest, using provide / inject consists of 2 steps

      1. Providing data
      2. Injecting provided data

      For examples of advanced uses of provide / inject, see this discussion.

      Using {% provide %} tagΒ€

      First we use the {% provide %} tag to define the data we want to "provide" (make available).

      {% provide "my_data" key="hi" another=123 %}
           {% component "child" / %}  <--- Can access "my_data"
       {% endprovide %}
       
      diff --git a/dev/concepts/advanced/rendering_js_css/index.html b/dev/concepts/advanced/rendering_js_css/index.html
      index cfa45c92..ff5c1765 100644
      --- a/dev/concepts/advanced/rendering_js_css/index.html
      +++ b/dev/concepts/advanced/rendering_js_css/index.html
      @@ -1,4 +1,4 @@
      - Rendering JS / CSS - Django-Components      

      Rendering JS / CSS

      JS and CSS output locationsΒ€

      If:

      1. Your components use JS and CSS via any of:
      2. And you use the ComponentDependencyMiddleware middleware

      Then, by default, the components' JS and CSS will be automatically inserted into the HTML:

      • CSS styles will be inserted at the end of the <head>
      • JS scripts will be inserted at the end of the <body>

      If you want to place the dependencies elsewhere in the HTML, you can override the locations by inserting following Django template tags:

      So if you have a component with JS and CSS:

      from django_components import Component, types
      + Rendering JS / CSS - Django-Components      

      Rendering JS / CSS

      JS and CSS output locationsΒ€

      If:

      1. Your components use JS and CSS via any of:
      2. And you use the ComponentDependencyMiddleware middleware

      Then, by default, the components' JS and CSS will be automatically inserted into the HTML:

      • CSS styles will be inserted at the end of the <head>
      • JS scripts will be inserted at the end of the <body>

      If you want to place the dependencies elsewhere in the HTML, you can override the locations by inserting following Django template tags:

      So if you have a component with JS and CSS:

      from django_components import Component, types
       
       class MyButton(Component):
           template: types.django_html = """
      diff --git a/dev/concepts/advanced/tag_formatter/index.html b/dev/concepts/advanced/tag_formatter/index.html
      index cd1c44aa..0302b833 100644
      --- a/dev/concepts/advanced/tag_formatter/index.html
      +++ b/dev/concepts/advanced/tag_formatter/index.html
      @@ -1,4 +1,4 @@
      - Tag formatters - Django-Components      

      Tag formatters

      Customizing component tags with TagFormatterΒ€

      New in version 0.89

      By default, components are rendered using the pair of {% component %} / {% endcomponent %} template tags:

      {% component "button" href="..." disabled %}
      + Tag formatters - Django-Components      

      Tag formatters

      Customizing component tags with TagFormatterΒ€

      New in version 0.89

      By default, components are rendered using the pair of {% component %} / {% endcomponent %} template tags:

      {% component "button" href="..." disabled %}
       Click me!
       {% endcomponent %}
       
      diff --git a/dev/concepts/advanced/typing_and_validation/index.html b/dev/concepts/advanced/typing_and_validation/index.html
      index 50395d73..d05d3f80 100644
      --- a/dev/concepts/advanced/typing_and_validation/index.html
      +++ b/dev/concepts/advanced/typing_and_validation/index.html
      @@ -1,4 +1,4 @@
      - Typing and validation - Django-Components      

      Typing and validation

      Adding type hints with GenericsΒ€

      New in version 0.92

      The Component class optionally accepts type parameters that allow you to specify the types of args, kwargs, slots, and data:

      class Button(Component[Args, Kwargs, Slots, Data, JsData, CssData]):
      + Typing and validation - Django-Components      

      Typing and validation

      Adding type hints with GenericsΒ€

      New in version 0.92

      The Component class optionally accepts type parameters that allow you to specify the types of args, kwargs, slots, and data:

      class Button(Component[Args, Kwargs, Slots, Data, JsData, CssData]):
           ...
       
      • Args - Must be a Tuple or Any
      • Kwargs - Must be a TypedDict or Any
      • Data - Must be a TypedDict or Any
      • Slots - Must be a TypedDict or Any

      Here's a full example:

      from typing import NotRequired, Tuple, TypedDict, SlotContent, SlotFunc
       
      diff --git a/dev/concepts/fundamentals/access_component_input/index.html b/dev/concepts/fundamentals/access_component_input/index.html
      index 0cc91d46..6573e9c4 100644
      --- a/dev/concepts/fundamentals/access_component_input/index.html
      +++ b/dev/concepts/fundamentals/access_component_input/index.html
      @@ -1,4 +1,4 @@
      - Accessing component inputs - Django-Components     

      Accessing component inputs

      When you call Component.render or Component.render_to_response, the inputs to these methods can be accessed from within the instance under self.input.

      This means that you can use self.input inside:

      • get_context_data
      • get_template_name
      • get_template
      • on_render_before
      • on_render_after

      self.input is only defined during the execution of Component.render, and raises a RuntimeError when called outside of this context.

      self.input has the same fields as the input to Component.render:

      class TestComponent(Component):
      + Accessing component inputs - Django-Components     

      Accessing component inputs

      When you call Component.render or Component.render_to_response, the inputs to these methods can be accessed from within the instance under self.input.

      This means that you can use self.input inside:

      • get_context_data
      • get_template_name
      • get_template
      • on_render_before
      • on_render_after

      self.input is only defined during the execution of Component.render, and raises a RuntimeError when called outside of this context.

      self.input has the same fields as the input to Component.render:

      class TestComponent(Component):
           def get_context_data(self, var1, var2, variable, another, **attrs):
               assert self.input.args == (123, "str")
               assert self.input.kwargs == {"variable": "test", "another": 1}
      diff --git a/dev/concepts/fundamentals/autodiscovery/index.html b/dev/concepts/fundamentals/autodiscovery/index.html
      index 3b806446..c2e4d561 100644
      --- a/dev/concepts/fundamentals/autodiscovery/index.html
      +++ b/dev/concepts/fundamentals/autodiscovery/index.html
      @@ -1,4 +1,4 @@
      - Autodiscovery - Django-Components      

      Autodiscovery

      Every component that you want to use in the template with the {% component %} tag needs to be registered with the ComponentRegistry. Normally, we use the @register decorator for that:

      from django_components import Component, register
      + Autodiscovery - Django-Components      

      Autodiscovery

      Every component that you want to use in the template with the {% component %} tag needs to be registered with the ComponentRegistry. Normally, we use the @register decorator for that:

      from django_components import Component, register
       
       @register("calendar")
       class Calendar(Component):
      diff --git a/dev/concepts/fundamentals/component_context_scope/index.html b/dev/concepts/fundamentals/component_context_scope/index.html
      index 8d9b06af..fec63d9d 100644
      --- a/dev/concepts/fundamentals/component_context_scope/index.html
      +++ b/dev/concepts/fundamentals/component_context_scope/index.html
      @@ -1,4 +1,4 @@
      - Component context and scope - Django-Components      

      Component context and scope

      By default, context variables are passed down the template as in regular Django - deeper scopes can access the variables from the outer scopes. So if you have several nested forloops, then inside the deep-most loop you can access variables defined by all previous loops.

      With this in mind, the {% component %} tag behaves similarly to {% include %} tag - inside the component tag, you can access all variables that were defined outside of it.

      And just like with {% include %}, if you don't want a specific component template to have access to the parent context, add only to the {% component %} tag:

      {% component "calendar" date="2015-06-19" only / %}
      + Component context and scope - Django-Components      

      Component context and scope

      By default, context variables are passed down the template as in regular Django - deeper scopes can access the variables from the outer scopes. So if you have several nested forloops, then inside the deep-most loop you can access variables defined by all previous loops.

      With this in mind, the {% component %} tag behaves similarly to {% include %} tag - inside the component tag, you can access all variables that were defined outside of it.

      And just like with {% include %}, if you don't want a specific component template to have access to the parent context, add only to the {% component %} tag:

      {% component "calendar" date="2015-06-19" only / %}
       

      NOTE: {% csrf_token %} tags need access to the top-level context, and they will not function properly if they are rendered in a component that is called with the only modifier.

      If you find yourself using the only modifier often, you can set the context_behavior option to "isolated", which automatically applies the only modifier. This is useful if you want to make sure that components don't accidentally access the outer context.

      Components can also access the outer context in their context methods like get_context_data by accessing the property self.outer_context.

      Example of Accessing Outer ContextΒ€

      <div>
         {% component "calender" / %}
       </div>
      diff --git a/dev/concepts/fundamentals/components_as_views/index.html b/dev/concepts/fundamentals/components_as_views/index.html
      index 02eb0922..a02be55a 100644
      --- a/dev/concepts/fundamentals/components_as_views/index.html
      +++ b/dev/concepts/fundamentals/components_as_views/index.html
      @@ -1,4 +1,4 @@
      - Components as views - Django-Components      

      Components as views

      New in version 0.34

      Note: Since 0.92, Component no longer subclasses View. To configure the View class, set the nested Component.View class

      Components can now be used as views:

      • Components define the Component.as_view() class method that can be used the same as View.as_view().

      • By default, you can define GET, POST or other HTTP handlers directly on the Component, same as you do with View. For example, you can override get and post to handle GET and POST requests, respectively.

      • In addition, Component now has a render_to_response method that renders the component template based on the provided context and slots' data and returns an HttpResponse object.

      Component as view exampleΒ€

      Here's an example of a calendar component defined as a view:

      # In a file called [project root]/components/calendar.py
      + Components as views - Django-Components      

      Components as views

      New in version 0.34

      Note: Since 0.92, Component no longer subclasses View. To configure the View class, set the nested Component.View class

      Components can now be used as views:

      • Components define the Component.as_view() class method that can be used the same as View.as_view().

      • By default, you can define GET, POST or other HTTP handlers directly on the Component, same as you do with View. For example, you can override get and post to handle GET and POST requests, respectively.

      • In addition, Component now has a render_to_response method that renders the component template based on the provided context and slots' data and returns an HttpResponse object.

      Component as view exampleΒ€

      Here's an example of a calendar component defined as a view:

      # In a file called [project root]/components/calendar.py
       from django_components import Component, ComponentView, register
       
       @register("calendar")
      diff --git a/dev/concepts/fundamentals/components_in_python/index.html b/dev/concepts/fundamentals/components_in_python/index.html
      index c9cadd2e..22067633 100644
      --- a/dev/concepts/fundamentals/components_in_python/index.html
      +++ b/dev/concepts/fundamentals/components_in_python/index.html
      @@ -1,4 +1,4 @@
      - Components in Python - Django-Components      

      Components in Python

      New in version 0.81

      Components can be rendered outside of Django templates, calling them as regular functions ("React-style").

      The component class defines render and render_to_response class methods. These methods accept positional args, kwargs, and slots, offering the same flexibility as the {% component %} tag:

      class SimpleComponent(Component):
      + Components in Python - Django-Components      

      Components in Python

      New in version 0.81

      Components can be rendered outside of Django templates, calling them as regular functions ("React-style").

      The component class defines render and render_to_response class methods. These methods accept positional args, kwargs, and slots, offering the same flexibility as the {% component %} tag:

      class SimpleComponent(Component):
           template = """
               {% load component_tags %}
               hello: {{ hello }}
      diff --git a/dev/concepts/fundamentals/defining_js_css_html_files/index.html b/dev/concepts/fundamentals/defining_js_css_html_files/index.html
      index 805ef11d..121e7b94 100644
      --- a/dev/concepts/fundamentals/defining_js_css_html_files/index.html
      +++ b/dev/concepts/fundamentals/defining_js_css_html_files/index.html
      @@ -1,4 +1,4 @@
      - Defining HTML / JS / CSS files - Django-Components      

      Defining HTML / JS / CSS files

      As you could have seen in the tutorial, there's multiple ways how you can associate HTML / JS / CSS with a component:

      Warning

      You cannot use both inlined code and separate file for a single language type:

      • You can only either set Component.template or Component.template_name
      • You can only either set Component.css or Component.css_file
      • You can only either set Component.js or Component.js_file

      However, you can freely mix these for different languages:

      class MyTable(Component):
      + Defining HTML / JS / CSS files - Django-Components      

      Defining HTML / JS / CSS files

      As you could have seen in the tutorial, there's multiple ways how you can associate HTML / JS / CSS with a component:

      Warning

      You cannot use both inlined code and separate file for a single language type:

      • You can only either set Component.template or Component.template_name
      • You can only either set Component.css or Component.css_file
      • You can only either set Component.js or Component.js_file

      However, you can freely mix these for different languages:

      class MyTable(Component):
           template: types.django_html = """
             <div class="welcome">
               Hi there!
      diff --git a/dev/concepts/fundamentals/html_attributes/index.html b/dev/concepts/fundamentals/html_attributes/index.html
      index 19e03f17..210089a5 100644
      --- a/dev/concepts/fundamentals/html_attributes/index.html
      +++ b/dev/concepts/fundamentals/html_attributes/index.html
      @@ -1,4 +1,4 @@
      - HTML attributes - Django-Components      

      HTML attributes

      New in version 0.74:

      You can use the html_attrs tag to render HTML attributes, given a dictionary of values.

      So if you have a template:

      <div class="{{ classes }}" data-id="{{ my_id }}">
      + HTML attributes - Django-Components      

      HTML attributes

      New in version 0.74:

      You can use the html_attrs tag to render HTML attributes, given a dictionary of values.

      So if you have a template:

      <div class="{{ classes }}" data-id="{{ my_id }}">
       </div>
       

      You can simplify it with html_attrs tag:

      <div {% html_attrs attrs %}>
       </div>
      diff --git a/dev/concepts/fundamentals/single_file_components/index.html b/dev/concepts/fundamentals/single_file_components/index.html
      index dc4a802d..34512f59 100644
      --- a/dev/concepts/fundamentals/single_file_components/index.html
      +++ b/dev/concepts/fundamentals/single_file_components/index.html
      @@ -1,4 +1,4 @@
      - Single-file components - Django-Components     

      Single-file components

      Components can be defined in a single file, which is useful for small components. To do this, you can use the template, js, and css class attributes instead of the template_name and Media. For example, here's the calendar component from above, defined in a single file:

      [project root]/components/calendar.py
      # In a file called [project root]/components/calendar.py
      + Single-file components - Django-Components     

      Single-file components

      Components can be defined in a single file, which is useful for small components. To do this, you can use the template, js, and css class attributes instead of the template_name and Media. For example, here's the calendar component from above, defined in a single file:

      [project root]/components/calendar.py
      # In a file called [project root]/components/calendar.py
       from django_components import Component, register, types
       
       @register("calendar")
      diff --git a/dev/concepts/fundamentals/slots/index.html b/dev/concepts/fundamentals/slots/index.html
      index 20d2e78a..e6b0704d 100644
      --- a/dev/concepts/fundamentals/slots/index.html
      +++ b/dev/concepts/fundamentals/slots/index.html
      @@ -1,4 +1,4 @@
      - Slots - Django-Components      

      Slots

      New in version 0.26:

      • The slot tag now serves only to declare new slots inside the component template.
      • To override the content of a declared slot, use the newly introduced fill tag instead.
      • Whereas unfilled slots used to raise a warning, filling a slot is now optional by default.
      • To indicate that a slot must be filled, the new required option should be added at the end of the slot tag.

      Components support something called 'slots'. When a component is used inside another template, slots allow the parent template to override specific parts of the child component by passing in different content. This mechanism makes components more reusable and composable. This behavior is similar to slots in Vue.

      In the example below we introduce two block tags that work hand in hand to make this work. These are...

      • {% slot <name> %}/{% endslot %}: Declares a new slot in the component template.
      • {% fill <name> %}/{% endfill %}: (Used inside a {% component %} tag pair.) Fills a declared slot with the specified content.

      Let's update our calendar component to support more customization. We'll add slot tag pairs to its template, template.html.

      <div class="calendar-component">
      + Slots - Django-Components      

      Slots

      New in version 0.26:

      • The slot tag now serves only to declare new slots inside the component template.
      • To override the content of a declared slot, use the newly introduced fill tag instead.
      • Whereas unfilled slots used to raise a warning, filling a slot is now optional by default.
      • To indicate that a slot must be filled, the new required option should be added at the end of the slot tag.

      Components support something called 'slots'. When a component is used inside another template, slots allow the parent template to override specific parts of the child component by passing in different content. This mechanism makes components more reusable and composable. This behavior is similar to slots in Vue.

      In the example below we introduce two block tags that work hand in hand to make this work. These are...

      • {% slot <name> %}/{% endslot %}: Declares a new slot in the component template.
      • {% fill <name> %}/{% endfill %}: (Used inside a {% component %} tag pair.) Fills a declared slot with the specified content.

      Let's update our calendar component to support more customization. We'll add slot tag pairs to its template, template.html.

      <div class="calendar-component">
           <div class="header">
               {% slot "header" %}Calendar header{% endslot %}
           </div>
      diff --git a/dev/concepts/fundamentals/template_tag_syntax/index.html b/dev/concepts/fundamentals/template_tag_syntax/index.html
      index 4d76996b..af393c00 100644
      --- a/dev/concepts/fundamentals/template_tag_syntax/index.html
      +++ b/dev/concepts/fundamentals/template_tag_syntax/index.html
      @@ -1,4 +1,4 @@
      - Template tag syntax - Django-Components      

      Template tag syntax

      All template tags in django_component, like {% component %} or {% slot %}, and so on, support extra syntax that makes it possible to write components like in Vue or React (JSX).

      Self-closing tagsΒ€

      When you have a tag like {% component %} or {% slot %}, but it has no content, you can simply append a forward slash / at the end, instead of writing out the closing tags like {% endcomponent %} or {% endslot %}:

      So this:

      {% component "button" %}{% endcomponent %}
      + Template tag syntax - Django-Components      

      Template tag syntax

      All template tags in django_component, like {% component %} or {% slot %}, and so on, support extra syntax that makes it possible to write components like in Vue or React (JSX).

      Self-closing tagsΒ€

      When you have a tag like {% component %} or {% slot %}, but it has no content, you can simply append a forward slash / at the end, instead of writing out the closing tags like {% endcomponent %} or {% endslot %}:

      So this:

      {% component "button" %}{% endcomponent %}
       

      becomes

      {% component "button" / %}
       

      Special charactersΒ€

      New in version 0.71:

      Keyword arguments can contain special characters # @ . - _, so keywords like so are still valid:

      <body>
           {% component "calendar" my-date="2015-06-19" @click.native=do_something #some_id=True / %}
      diff --git a/dev/concepts/getting_started/adding_js_and_css/index.html b/dev/concepts/getting_started/adding_js_and_css/index.html
      index f7947033..5101129a 100644
      --- a/dev/concepts/getting_started/adding_js_and_css/index.html
      +++ b/dev/concepts/getting_started/adding_js_and_css/index.html
      @@ -1,4 +1,4 @@
      - Adding JS and CSS - Django-Components      

      Adding JS and CSS

      Next we will add CSS and JavaScript to our template.

      Info

      In django-components, using JS and CSS is as simple as defining them on the Component class. You don't have to insert the <script> and <link> tags into the HTML manually.

      Behind the scenes, django-components keeps track of which components use which JS and CSS files. Thus, when a component is rendered on the page, the page will contain only the JS and CSS used by the components, and nothing more!

      1. Update project structureΒ€

      Start by creating empty calendar.js and calendar.css files:

      sampleproject/
      + Adding JS and CSS - Django-Components      

      Adding JS and CSS

      Next we will add CSS and JavaScript to our template.

      Info

      In django-components, using JS and CSS is as simple as defining them on the Component class. You don't have to insert the <script> and <link> tags into the HTML manually.

      Behind the scenes, django-components keeps track of which components use which JS and CSS files. Thus, when a component is rendered on the page, the page will contain only the JS and CSS used by the components, and nothing more!

      1. Update project structureΒ€

      Start by creating empty calendar.js and calendar.css files:

      sampleproject/
       β”œβ”€β”€ calendarapp/
       β”œβ”€β”€ components/
       β”‚   └── calendar/
      diff --git a/dev/concepts/getting_started/adding_slots/index.html b/dev/concepts/getting_started/adding_slots/index.html
      index 1d31966f..92d75191 100644
      --- a/dev/concepts/getting_started/adding_slots/index.html
      +++ b/dev/concepts/getting_started/adding_slots/index.html
      @@ -1,4 +1,4 @@
      - Adding slots - Django-Components      

      Adding slots

      Our calendar component's looking great! But we just got a new assignment from our colleague - The calendar date needs to be shown on 3 different pages:

      1. On one page, it needs to be shown as is
      2. On the second, the date needs to be bold
      3. On the third, the date needs to be in italics

      As a reminder, this is what the component's template looks like:

      <div class="calendar">
      + Adding slots - Django-Components      

      Adding slots

      Our calendar component's looking great! But we just got a new assignment from our colleague - The calendar date needs to be shown on 3 different pages:

      1. On one page, it needs to be shown as is
      2. On the second, the date needs to be bold
      3. On the third, the date needs to be in italics

      As a reminder, this is what the component's template looks like:

      <div class="calendar">
         Today's date is <span>{{ date }}</span>
       </div>
       

      There's many ways we could approach this:

      • Expose the date in a slot
      • Style .calendar > span differently on different pages
      • Pass a variable to the component that decides how the date is rendered
      • Create a new component

      First two options are more flexible, because the custom styling is not baked into a component's implementation. And for the sake of demonstration, we'll solve this challenge with slots.

      1. What are slotsΒ€

      Components support something called Slots.

      When a component is used inside another template, slots allow the parent template to override specific parts of the child component by passing in different content.

      This mechanism makes components more reusable and composable.

      This behavior is similar to slots in Vue.

      In the example below we introduce two tags that work hand in hand to make this work. These are...

      • {% slot <name> %}/{% endslot %}: Declares a new slot in the component template.
      • {% fill <name> %}/{% endfill %}: (Used inside a {% component %} tag pair.) Fills a declared slot with the specified content.

      2. Add a slot tagΒ€

      Let's update our calendar component to support more customization. We'll add {% slot %} tag to the template:

      <div class="calendar">
      diff --git a/dev/concepts/getting_started/components_in_templates/index.html b/dev/concepts/getting_started/components_in_templates/index.html
      index ec4bc9d2..e3e81c95 100644
      --- a/dev/concepts/getting_started/components_in_templates/index.html
      +++ b/dev/concepts/getting_started/components_in_templates/index.html
      @@ -1,4 +1,4 @@
      - Components in templates - Django-Components      

      Components in templates

      By the end of this section, we want to be able to use our components in Django templates like so:

      {% load component_tags %}
      + Components in templates - Django-Components      

      Components in templates

      By the end of this section, we want to be able to use our components in Django templates like so:

      {% load component_tags %}
       <!DOCTYPE html>
       <html>
         <head>
      diff --git a/dev/concepts/getting_started/parametrising_components/index.html b/dev/concepts/getting_started/parametrising_components/index.html
      index c1f405f2..4cbc3e87 100644
      --- a/dev/concepts/getting_started/parametrising_components/index.html
      +++ b/dev/concepts/getting_started/parametrising_components/index.html
      @@ -1,4 +1,4 @@
      - Parametrising components - Django-Components      

      Parametrising components

      So far, our Calendar component will always render the date 1970-01-01. Let's make it more useful and flexible by being able to pass in custom date.

      What we want is to be able to use the Calendar component within the template like so:

      {% component "calendar" date="2024-12-13" extra_class="text-red" / %}
      + Parametrising components - Django-Components      

      Parametrising components

      So far, our Calendar component will always render the date 1970-01-01. Let's make it more useful and flexible by being able to pass in custom date.

      What we want is to be able to use the Calendar component within the template like so:

      {% component "calendar" date="2024-12-13" extra_class="text-red" / %}
       

      1. Understading component inputsΒ€

      In section Create your first component, we defined the get_context_data() method that defines what variables will be available within the template:

      [project root]/components/calendar/calendar.py
      from django_components import Component, register
       
       @register("calendar")
      diff --git a/dev/concepts/getting_started/your_first_component/index.html b/dev/concepts/getting_started/your_first_component/index.html
      index 08d95ba5..0d8dc3b9 100644
      --- a/dev/concepts/getting_started/your_first_component/index.html
      +++ b/dev/concepts/getting_started/your_first_component/index.html
      @@ -1,4 +1,4 @@
      - Create your first component - Django-Components      

      Create your first component

      A component in django-components can be as simple as a Django template and Python code to declare the component:

      calendar.html
      <div class="calendar">
      + Create your first component - Django-Components      

      Create your first component

      A component in django-components can be as simple as a Django template and Python code to declare the component:

      calendar.html
      <div class="calendar">
         Today's date is <span>{{ date }}</span>
       </div>
       
      calendar.py
      from django_components import Component
      diff --git a/dev/guides/devguides/dependency_mgmt/index.html b/dev/guides/devguides/dependency_mgmt/index.html
      index 58f954e0..c49f62aa 100644
      --- a/dev/guides/devguides/dependency_mgmt/index.html
      +++ b/dev/guides/devguides/dependency_mgmt/index.html
      @@ -1,4 +1,4 @@
      - JS and CSS rendering - Django-Components      

      JS and CSS renderingΒ€

      Aim of this doc is to share the intuition on how we manage the JS and CSS ("dependencies") associated with components, and how we render them.

      Starting conditionsΒ€

      1. First of all, when we consider a component, it has two kind of dependencies - the "inlined" JS and CSS, and additional linked JS and CSS via Media.js/css:
      from django_components import Component, types
      + JS and CSS rendering - Django-Components      

      JS and CSS renderingΒ€

      Aim of this doc is to share the intuition on how we manage the JS and CSS ("dependencies") associated with components, and how we render them.

      Starting conditionsΒ€

      1. First of all, when we consider a component, it has two kind of dependencies - the "inlined" JS and CSS, and additional linked JS and CSS via Media.js/css:
      from django_components import Component, types
       
       class MyTable(Component):
           # Inlined JS
      diff --git a/dev/guides/devguides/slot_rendering/index.html b/dev/guides/devguides/slot_rendering/index.html
      index df2481cd..5621de54 100644
      --- a/dev/guides/devguides/slot_rendering/index.html
      +++ b/dev/guides/devguides/slot_rendering/index.html
      @@ -1,4 +1,4 @@
      - Slot rendering - Django-Components      

      Slot renderingΒ€

      This doc serves as a primer on how component slots and fills are resolved.

      FlowΒ€

      1. Imagine you have a template. Some kind of text, maybe HTML:

        | ------
        + Slot rendering - Django-Components      

        Slot renderingΒ€

        This doc serves as a primer on how component slots and fills are resolved.

        FlowΒ€

        1. Imagine you have a template. Some kind of text, maybe HTML:

          | ------
           | ---------
           | ----
           | -------
          diff --git a/dev/guides/devguides/slots_and_blocks/index.html b/dev/guides/devguides/slots_and_blocks/index.html
          index effd0a05..ce155f51 100644
          --- a/dev/guides/devguides/slots_and_blocks/index.html
          +++ b/dev/guides/devguides/slots_and_blocks/index.html
          @@ -1,4 +1,4 @@
          - Using slot and block tags - Django-Components      

          Using slot and block tagsΒ€

          1. First let's clarify how include and extends tags work inside components. So when component template includes include or extends tags, it's as if the "included" template was inlined. So if the "included" template contains slot tags, then the component uses those slots.

            So if you have a template `abc.html`:
            + Using slot and block tags - Django-Components      

            Using slot and block tagsΒ€

            1. First let's clarify how include and extends tags work inside components. So when component template includes include or extends tags, it's as if the "included" template was inlined. So if the "included" template contains slot tags, then the component uses those slots.

              So if you have a template `abc.html`:
               ```django
               <div>
                 hello
              diff --git a/dev/guides/setup/dev_server_setup/index.html b/dev/guides/setup/dev_server_setup/index.html
              index a73ce2d1..b389b584 100644
              --- a/dev/guides/setup/dev_server_setup/index.html
              +++ b/dev/guides/setup/dev_server_setup/index.html
              @@ -1 +1 @@
              - Running with development server - Django-Components      

              Running with development server

              Reload dev server on component file changesΒ€

              This is relevant if you are using the project structure as shown in our examples, where HTML, JS, CSS and Python are in separate files and nested in a directory.

              In this case you may notice that when you are running a development server, the server sometimes does not reload when you change component files.

              From relevant StackOverflow thread:

              TL;DR is that the server won't reload if it thinks the changed file is in a templates directory, or in a nested sub directory of a templates directory. This is by design.

              To make the dev server reload on all component files, set reload_on_file_change to True. This configures Django to watch for component files too.

              Note

              This setting should be enabled only for the dev environment!

              \ No newline at end of file + Running with development server - Django-Components

              Running with development server

              Reload dev server on component file changesΒ€

              This is relevant if you are using the project structure as shown in our examples, where HTML, JS, CSS and Python are in separate files and nested in a directory.

              In this case you may notice that when you are running a development server, the server sometimes does not reload when you change component files.

              From relevant StackOverflow thread:

              TL;DR is that the server won't reload if it thinks the changed file is in a templates directory, or in a nested sub directory of a templates directory. This is by design.

              To make the dev server reload on all component files, set reload_on_file_change to True. This configures Django to watch for component files too.

              Note

              This setting should be enabled only for the dev environment!

              \ No newline at end of file diff --git a/dev/guides/setup/logging_and_debugging/index.html b/dev/guides/setup/logging_and_debugging/index.html index 052eb894..0b89a057 100644 --- a/dev/guides/setup/logging_and_debugging/index.html +++ b/dev/guides/setup/logging_and_debugging/index.html @@ -1,4 +1,4 @@ - Logging and debugging - Django-Components

              Logging and debugging

              Django components supports logging with Django. This can help with troubleshooting.

              To configure logging for Django components, set the django_components logger in LOGGING in settings.py (below).

              Also see the settings.py file in sampleproject for a real-life example.

              import logging
              + Logging and debugging - Django-Components     

              Logging and debugging

              Django components supports logging with Django. This can help with troubleshooting.

              To configure logging for Django components, set the django_components logger in LOGGING in settings.py (below).

              Also see the settings.py file in sampleproject for a real-life example.

              import logging
               import sys
               
               LOGGING = {
              diff --git a/dev/guides/setup/syntax_highlight/index.html b/dev/guides/setup/syntax_highlight/index.html
              index 64653c4a..74a53c77 100644
              --- a/dev/guides/setup/syntax_highlight/index.html
              +++ b/dev/guides/setup/syntax_highlight/index.html
              @@ -1,4 +1,4 @@
              - Syntax highlighting - Django-Components      

              Syntax highlighting

              VSCodeΒ€

              1. First install Python Inline Source Syntax Highlighting extension, it will give you syntax highlighting for the template, CSS, and JS.

              2. Next, in your component, set typings of Component.template/css/js to types.django_html, types.css, and types.js respectively. The extension will recognize these and will activate syntax highlighting.

              [project root]/components/calendar.py
              # In a file called [project root]/components/calendar.py
              + Syntax highlighting - Django-Components      

              Syntax highlighting

              VSCodeΒ€

              1. First install Python Inline Source Syntax Highlighting extension, it will give you syntax highlighting for the template, CSS, and JS.

              2. Next, in your component, set typings of Component.template/css/js to types.django_html, types.css, and types.js respectively. The extension will recognize these and will activate syntax highlighting.

              [project root]/components/calendar.py
              # In a file called [project root]/components/calendar.py
               from django_components import Component, register, types
               
               @register("calendar")
              diff --git a/dev/migrating_from_safer_staticfiles/index.html b/dev/migrating_from_safer_staticfiles/index.html
              index 3bf7e415..2f11939b 100644
              --- a/dev/migrating_from_safer_staticfiles/index.html
              +++ b/dev/migrating_from_safer_staticfiles/index.html
              @@ -1,4 +1,4 @@
              - Migrating from safer_staticfiles - Django-Components      

              Migrating from safer_staticfilesΒ€

              This guide is for you if you're upgrating django_components to v0.100 or later from older versions.

              In version 0.100, we changed how components' static JS and CSS files are handled. See more in the "Static files" section.

              Migration steps:

              1. Remove django_components.safer_staticfiles from INSTALLED_APPS in your settings.py, and replace it with django.contrib.staticfiles.

              Before:

              INSTALLED_APPS = [
              + Migrating from safer_staticfiles - Django-Components      

              Migrating from safer_staticfilesΒ€

              This guide is for you if you're upgrating django_components to v0.100 or later from older versions.

              In version 0.100, we changed how components' static JS and CSS files are handled. See more in the "Static files" section.

              Migration steps:

              1. Remove django_components.safer_staticfiles from INSTALLED_APPS in your settings.py, and replace it with django.contrib.staticfiles.

              Before:

              INSTALLED_APPS = [
                  "django.contrib.admin",
                  ...
                  # "django.contrib.staticfiles",  # <-- ADD
              diff --git a/dev/overrides/main.html b/dev/overrides/main.html
              deleted file mode 100644
              index dc85d397..00000000
              --- a/dev/overrides/main.html
              +++ /dev/null
              @@ -1,5 +0,0 @@
              -{% extends "base.html" %}
              -
              -{% block announce %}
              - 🚨The documentation is still a work in progress. 🚨
              -{% endblock %}
              \ No newline at end of file
              diff --git a/dev/overview/code_of_conduct/index.html b/dev/overview/code_of_conduct/index.html
              index 423d7bc3..8383876b 100644
              --- a/dev/overview/code_of_conduct/index.html
              +++ b/dev/overview/code_of_conduct/index.html
              @@ -1 +1 @@
              - Code of Conduct - Django-Components      

              Contributor Covenant Code of ConductΒ€

              Our PledgeΒ€

              In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

              Our StandardsΒ€

              Examples of behavior that contributes to creating a positive environment include:

              • Using welcoming and inclusive language
              • Being respectful of differing viewpoints and experiences
              • Gracefully accepting constructive criticism
              • Focusing on what is best for the community
              • Showing empathy towards other community members

              Examples of unacceptable behavior by participants include:

              • The use of sexualized language or imagery and unwelcome sexual attention or advances
              • Trolling, insulting/derogatory comments, and personal or political attacks
              • Public or private harassment
              • Publishing others' private information, such as a physical or electronic address, without explicit permission
              • Other conduct which could reasonably be considered inappropriate in a professional setting

              Our ResponsibilitiesΒ€

              Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

              Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

              ScopeΒ€

              This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

              EnforcementΒ€

              Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at emil@emilstenstrom.se. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

              Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

              AttributionΒ€

              This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

              For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq

              \ No newline at end of file + Code of Conduct - Django-Components

              Contributor Covenant Code of ConductΒ€

              Our PledgeΒ€

              In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

              Our StandardsΒ€

              Examples of behavior that contributes to creating a positive environment include:

              • Using welcoming and inclusive language
              • Being respectful of differing viewpoints and experiences
              • Gracefully accepting constructive criticism
              • Focusing on what is best for the community
              • Showing empathy towards other community members

              Examples of unacceptable behavior by participants include:

              • The use of sexualized language or imagery and unwelcome sexual attention or advances
              • Trolling, insulting/derogatory comments, and personal or political attacks
              • Public or private harassment
              • Publishing others' private information, such as a physical or electronic address, without explicit permission
              • Other conduct which could reasonably be considered inappropriate in a professional setting

              Our ResponsibilitiesΒ€

              Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

              Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

              ScopeΒ€

              This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

              EnforcementΒ€

              Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at emil@emilstenstrom.se. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

              Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

              AttributionΒ€

              This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

              For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq

              \ No newline at end of file diff --git a/dev/overview/community/index.html b/dev/overview/community/index.html index 0c954fc0..bd68b6bd 100644 --- a/dev/overview/community/index.html +++ b/dev/overview/community/index.html @@ -1 +1 @@ - Community - Django-Components

              Community

              Community questionsΒ€

              The best place to ask questions is in our Github Discussion board.

              Please, before opening a new discussion, check if similar discussion wasn't opened already.

              Community examplesΒ€

              One of our goals with django-components is to make it easy to share components between projects (see how to package components). If you have a set of components that you think would be useful to others, please open a pull request to add them to the list below.

              \ No newline at end of file + Community - Django-Components

              Community

              Community questionsΒ€

              The best place to ask questions is in our Github Discussion board.

              Please, before opening a new discussion, check if similar discussion wasn't opened already.

              Community examplesΒ€

              One of our goals with django-components is to make it easy to share components between projects (see how to package components). If you have a set of components that you think would be useful to others, please open a pull request to add them to the list below.

              \ No newline at end of file diff --git a/dev/overview/compatibility/index.html b/dev/overview/compatibility/index.html index 34c1c439..6c21c604 100644 --- a/dev/overview/compatibility/index.html +++ b/dev/overview/compatibility/index.html @@ -1 +1 @@ - Compatibility - Django-Components

              Compatibility

              CompatibilityΒ€

              Django-components supports all supported combinations versions of Django and Python.

              Python version Django version
              3.8 4.2
              3.9 4.2
              3.10 4.2, 5.0, 5.1
              3.11 4.2, 5.0, 5.1
              3.12 4.2, 5.0, 5.1
              3.13 5.1
              \ No newline at end of file + Compatibility - Django-Components

              Compatibility

              CompatibilityΒ€

              Django-components supports all supported combinations versions of Django and Python.

              Python version Django version
              3.8 4.2
              3.9 4.2
              3.10 4.2, 5.0, 5.1
              3.11 4.2, 5.0, 5.1
              3.12 4.2, 5.0, 5.1
              3.13 5.1
              \ No newline at end of file diff --git a/dev/overview/contributing/index.html b/dev/overview/contributing/index.html index c48de7d8..7a155cd8 100644 --- a/dev/overview/contributing/index.html +++ b/dev/overview/contributing/index.html @@ -1 +1 @@ - Contributing - Django-Components

              Contributing

              Bug reportsΒ€

              If you find a bug, please open an issue with detailed description of what happened.

              Bug fixesΒ€

              If you found a fix for a bug or typo, go ahead and open a PR with a fix. We'll help you out with the rest!

              Feature requestsΒ€

              For feature requests or suggestions, please open either a discussion or an issue.

              Getting involvedΒ€

              django_components is still under active development, and there's much to build, so come aboard!

              SponsoringΒ€

              Another way you can get involved is by donating to the development of django_components.

              \ No newline at end of file + Contributing - Django-Components

              Contributing

              Bug reportsΒ€

              If you find a bug, please open an issue with detailed description of what happened.

              Bug fixesΒ€

              If you found a fix for a bug or typo, go ahead and open a PR with a fix. We'll help you out with the rest!

              Feature requestsΒ€

              For feature requests or suggestions, please open either a discussion or an issue.

              Getting involvedΒ€

              django_components is still under active development, and there's much to build, so come aboard!

              SponsoringΒ€

              Another way you can get involved is by donating to the development of django_components.

              \ No newline at end of file diff --git a/dev/overview/development/index.html b/dev/overview/development/index.html index ea3cf75f..c483484e 100644 --- a/dev/overview/development/index.html +++ b/dev/overview/development/index.html @@ -1,4 +1,4 @@ - Development - Django-Components

              Development

              Install locally and run the testsΒ€

              Start by forking the project by clicking the Fork button up in the right corner in the GitHub. This makes a copy of the repository in your own name. Now you can clone this repository locally and start adding features:

              git clone https://github.com/<your GitHub username>/django-components.git
              + Development - Django-Components      

              Development

              Install locally and run the testsΒ€

              Start by forking the project by clicking the Fork button up in the right corner in the GitHub. This makes a copy of the repository in your own name. Now you can clone this repository locally and start adding features:

              git clone https://github.com/<your GitHub username>/django-components.git
               

              To quickly run the tests install the local dependencies by running:

              pip install -r requirements-dev.txt
               

              Now you can run the tests to make sure everything works as expected:

              pytest
               

              The library is also tested across many versions of Python and Django. To run tests that way:

              pyenv install -s 3.8
              diff --git a/dev/overview/installation/index.html b/dev/overview/installation/index.html
              index 5d9cd8c0..fb61e20f 100644
              --- a/dev/overview/installation/index.html
              +++ b/dev/overview/installation/index.html
              @@ -1,4 +1,4 @@
              - Installation - Django-Components      

              Installation

              1. Install django_components into your environment:

                pip install django_components
                + Installation - Django-Components      

                Installation

                1. Install django_components into your environment:

                  pip install django_components
                   
                2. Load django_components into Django by adding it into INSTALLED_APPS in in your settings file:

                  INSTALLED_APPS = [
                       ...,
                       'django_components',
                  diff --git a/dev/overview/license/index.html b/dev/overview/license/index.html
                  index 5d20ea86..41efb62f 100644
                  --- a/dev/overview/license/index.html
                  +++ b/dev/overview/license/index.html
                  @@ -1 +1 @@
                  - License - Django-Components     

                  License

                  MIT License

                  Copyright (c) 2019 Emil StenstrΓΆm

                  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

                  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

                  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

                  \ No newline at end of file + License - Django-Components

                  License

                  MIT License

                  Copyright (c) 2019 Emil StenstrΓΆm

                  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

                  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

                  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

                  \ No newline at end of file diff --git a/dev/overview/security_notes/index.html b/dev/overview/security_notes/index.html index 29c301a9..f25a172d 100644 --- a/dev/overview/security_notes/index.html +++ b/dev/overview/security_notes/index.html @@ -1,4 +1,4 @@ - Security notes 🚨 - Django-Components

                  Security notes 🚨

                  It is strongly recommended to read this section before using django-components in production.

                  Static filesΒ€

                  Components can be organized however you prefer. That said, our prefered way is to keep the files of a component close together by bundling them in the same directory.

                  This means that files containing backend logic, such as Python modules and HTML templates, live in the same directory as static files, e.g. JS and CSS.

                  From v0.100 onwards, we keep component files (as defined by COMPONENTS.dirs and COMPONENTS.app_dirs) separate from the rest of the static files (defined by STATICFILES_DIRS). That way, the Python and HTML files are NOT exposed by the server. Only the static JS, CSS, and other common formats.

                  Note

                  If you need to expose different file formats, you can configure these with COMPONENTS.static_files_allowed and COMPONENTS.static_files_forbidden.

                  Static files prior to v0.100Β€

                  Prior to v0.100, if your were using django.contrib.staticfiles to collect static files, no distinction was made between the different kinds of files.

                  As a result, your Python code and templates may inadvertently become available on your static file server. You probably don't want this, as parts of your backend logic will be exposed, posing a potential security vulnerability.

                  From v0.27 until v0.100, django-components shipped with an additional installable app django_components.safer_staticfiles. It was a drop-in replacement for django.contrib.staticfiles. Its behavior is 100% identical except it ignores .py and .html files, meaning these will not end up on your static files server.

                  To use it, add it to INSTALLED_APPS and remove django.contrib.staticfiles.

                  INSTALLED_APPS = [
                  + Security notes 🚨 - Django-Components      

                  Security notes 🚨

                  It is strongly recommended to read this section before using django-components in production.

                  Static filesΒ€

                  Components can be organized however you prefer. That said, our prefered way is to keep the files of a component close together by bundling them in the same directory.

                  This means that files containing backend logic, such as Python modules and HTML templates, live in the same directory as static files, e.g. JS and CSS.

                  From v0.100 onwards, we keep component files (as defined by COMPONENTS.dirs and COMPONENTS.app_dirs) separate from the rest of the static files (defined by STATICFILES_DIRS). That way, the Python and HTML files are NOT exposed by the server. Only the static JS, CSS, and other common formats.

                  Note

                  If you need to expose different file formats, you can configure these with COMPONENTS.static_files_allowed and COMPONENTS.static_files_forbidden.

                  Static files prior to v0.100Β€

                  Prior to v0.100, if your were using django.contrib.staticfiles to collect static files, no distinction was made between the different kinds of files.

                  As a result, your Python code and templates may inadvertently become available on your static file server. You probably don't want this, as parts of your backend logic will be exposed, posing a potential security vulnerability.

                  From v0.27 until v0.100, django-components shipped with an additional installable app django_components.safer_staticfiles. It was a drop-in replacement for django.contrib.staticfiles. Its behavior is 100% identical except it ignores .py and .html files, meaning these will not end up on your static files server.

                  To use it, add it to INSTALLED_APPS and remove django.contrib.staticfiles.

                  INSTALLED_APPS = [
                       # 'django.contrib.staticfiles',   # <-- REMOVE
                       'django_components',
                       'django_components.safer_staticfiles'  # <-- ADD
                  diff --git a/dev/overview/welcome/index.html b/dev/overview/welcome/index.html
                  index 64ddc998..b91f4018 100644
                  --- a/dev/overview/welcome/index.html
                  +++ b/dev/overview/welcome/index.html
                  @@ -1,4 +1,4 @@
                  - Welcome to Django Components - Django-Components      

                  Welcome to Django Components

                  django-components

                  PyPI - Version PyPI - Python Version PyPI - License PyPI - Downloads GitHub Actions Workflow Status

                  django-components introduces component-based architecture to Django's server-side rendering. It combines Django's templating system with the modularity seen in modern frontend frameworks like Vue or React.

                  A component in django-components can be as simple as a Django template and Python code to declare the component:

                  calendar.html
                  <div class="calendar">
                  + Welcome to Django Components - Django-Components      

                  Welcome to Django Components

                  django-components

                  PyPI - Version PyPI - Python Version PyPI - License PyPI - Downloads GitHub Actions Workflow Status

                  django-components introduces component-based architecture to Django's server-side rendering. It combines Django's templating system with the modularity seen in modern frontend frameworks like Vue or React.

                  A component in django-components can be as simple as a Django template and Python code to declare the component:

                  calendar.html
                  <div class="calendar">
                     Today's date is <span>{{ date }}</span>
                   </div>
                   
                  calendar.py
                  from django_components import Component
                  diff --git a/dev/reference/api/index.html b/dev/reference/api/index.html
                  index 80b1b2ec..ca0356bd 100644
                  --- a/dev/reference/api/index.html
                  +++ b/dev/reference/api/index.html
                  @@ -1,4 +1,4 @@
                  - Api - Django-Components      

                  APIΒ€

                  Component Β€

                  Component(registered_name: Optional[str] = None, outer_context: Optional[Context] = None, registry: Optional[ComponentRegistry] = None)
                  + Api - Django-Components      

                  APIΒ€

                  Component Β€

                  Component(registered_name: Optional[str] = None, outer_context: Optional[Context] = None, registry: Optional[ComponentRegistry] = None)
                   

                  Methods:

                  Attributes:

                  Media class-attribute instance-attribute Β€

                  See source code

                  Defines JS and CSS media files associated with this component.

                  This Media class behaves similarly to Django's Media class:

                  • Paths are generally handled as static file paths, and resolved URLs are rendered to HTML with media_class.render_js() or media_class.render_css().
                  • A path that starts with http, https, or / is considered a URL, skipping the static file resolution. This path is still rendered to HTML with media_class.render_js() or media_class.render_css().
                  • A SafeString (with __html__ method) is considered an already-formatted HTML tag, skipping both static file resolution and rendering with media_class.render_js() or media_class.render_css().

                  However, there's a few differences from Django's Media class:

                  1. Our Media class accepts various formats for the JS and CSS files: either a single file, a list, or (CSS-only) a dictonary (See ComponentMediaInput).
                  2. Individual JS / CSS files can be any of str, bytes, Path, SafeString, or a function (See ComponentMediaInputPath).
                  3. Our Media class does NOT support Django's extend keyword

                  Example:

                  class MyTable(Component):
                       class Media:
                  diff --git a/dev/reference/commands/index.html b/dev/reference/commands/index.html
                  index 2db785b3..625939a3 100644
                  --- a/dev/reference/commands/index.html
                  +++ b/dev/reference/commands/index.html
                  @@ -1,4 +1,4 @@
                  - Commands - Django-Components      

                  CommandsΒ€

                  These are all the Django management commands that will be added by installing django_components:

                  upgradecomponentΒ€

                  usage: manage.py upgradecomponent [-h] [--path PATH] [--version]
                  + Commands - Django-Components      

                  CommandsΒ€

                  These are all the Django management commands that will be added by installing django_components:

                  upgradecomponentΒ€

                  usage: manage.py upgradecomponent [-h] [--path PATH] [--version]
                                                     [-v {0,1,2,3}] [--settings SETTINGS]
                                                     [--pythonpath PYTHONPATH] [--traceback]
                                                     [--no-color] [--force-color] [--skip-checks]
                  diff --git a/dev/reference/components/index.html b/dev/reference/components/index.html
                  index a552f983..36498791 100644
                  --- a/dev/reference/components/index.html
                  +++ b/dev/reference/components/index.html
                  @@ -1,4 +1,4 @@
                  - Components - Django-Components      

                  ComponentsΒ€

                  These are the components provided by django_components.

                  DynamicComponent Β€

                  Bases: django_components.component.Component

                  See source code

                  This component is given a registered name or a reference to another component, and behaves as if the other component was in its place.

                  The args, kwargs, and slot fills are all passed down to the underlying component.

                  Parameters:

                  • is (str | Type[Component]) –

                    Component that should be rendered. Either a registered name of a component, or a Component class directly. Required.

                  • registry (ComponentRegistry, default: None ) –

                    Specify the registry to search for the registered name. If omitted, all registries are searched until the first match.

                  • *args –

                    Additional data passed to the component.

                  • **kwargs –

                    Additional data passed to the component.

                  Slots:

                  • Any slots, depending on the actual component.

                  Examples:

                  Django

                  {% component "dynamic" is=table_comp data=table_data headers=table_headers %}
                  + Components - Django-Components      

                  ComponentsΒ€

                  These are the components provided by django_components.

                  DynamicComponent Β€

                  Bases: django_components.component.Component

                  See source code

                  This component is given a registered name or a reference to another component, and behaves as if the other component was in its place.

                  The args, kwargs, and slot fills are all passed down to the underlying component.

                  Parameters:

                  • is (str | Type[Component]) –

                    Component that should be rendered. Either a registered name of a component, or a Component class directly. Required.

                  • registry (ComponentRegistry, default: None ) –

                    Specify the registry to search for the registered name. If omitted, all registries are searched until the first match.

                  • *args –

                    Additional data passed to the component.

                  • **kwargs –

                    Additional data passed to the component.

                  Slots:

                  • Any slots, depending on the actual component.

                  Examples:

                  Django

                  {% component "dynamic" is=table_comp data=table_data headers=table_headers %}
                       {% fill "pagination" %}
                           {% component "pagination" / %}
                       {% endfill %}
                  diff --git a/dev/reference/exceptions/index.html b/dev/reference/exceptions/index.html
                  index 7d321b37..2e8bcad7 100644
                  --- a/dev/reference/exceptions/index.html
                  +++ b/dev/reference/exceptions/index.html
                  @@ -1,3 +1,3 @@
                  - Exceptions - Django-Components      

                  ExceptionsΒ€

                  AlreadyRegistered Β€

                  Bases: Exception

                  See source code

                  Raised when you try to register a Component, but it's already registered with given ComponentRegistry.

                  NotRegistered Β€

                  Bases: Exception

                  See source code

                  Raised when you try to access a Component, but it's NOT registered with given ComponentRegistry.

                  TagProtectedError Β€

                  Bases: Exception

                  See source code

                  The way the TagFormatter works is that, based on which start and end tags are used for rendering components, the ComponentRegistry behind the scenes un-/registers the template tags with the associated instance of Django's Library.

                  In other words, if I have registered a component "table", and I use the shorthand syntax:

                  {% table ... %}
                  + Exceptions - Django-Components      

                  ExceptionsΒ€

                  AlreadyRegistered Β€

                  Bases: Exception

                  See source code

                  Raised when you try to register a Component, but it's already registered with given ComponentRegistry.

                  NotRegistered Β€

                  Bases: Exception

                  See source code

                  Raised when you try to access a Component, but it's NOT registered with given ComponentRegistry.

                  TagProtectedError Β€

                  Bases: Exception

                  See source code

                  The way the TagFormatter works is that, based on which start and end tags are used for rendering components, the ComponentRegistry behind the scenes un-/registers the template tags with the associated instance of Django's Library.

                  In other words, if I have registered a component "table", and I use the shorthand syntax:

                  {% table ... %}
                   {% endtable %}
                   

                  Then ComponentRegistry registers the tag table onto the Django's Library instance.

                  However, that means that if we registered a component "slot", then we would overwrite the {% slot %} tag from django_components.

                  Thus, this exception is raised when a component is attempted to be registered under a forbidden name, such that it would overwrite one of django_component's own template tags.

                  \ No newline at end of file diff --git a/dev/reference/middlewares/index.html b/dev/reference/middlewares/index.html index 17c74d56..e8182132 100644 --- a/dev/reference/middlewares/index.html +++ b/dev/reference/middlewares/index.html @@ -1 +1 @@ - Middlewares - Django-Components

                  MiddlewaresΒ€

                  ComponentDependencyMiddleware Β€

                  Bases: object

                  See source code

                  Middleware that inserts CSS/JS dependencies for all rendered components at points marked with template tags.

                  \ No newline at end of file + Middlewares - Django-Components

                  MiddlewaresΒ€

                  ComponentDependencyMiddleware Β€

                  Bases: object

                  See source code

                  Middleware that inserts CSS/JS dependencies for all rendered components at points marked with template tags.

                  \ No newline at end of file diff --git a/dev/reference/settings/index.html b/dev/reference/settings/index.html index 1a014649..d4db06d5 100644 --- a/dev/reference/settings/index.html +++ b/dev/reference/settings/index.html @@ -1,4 +1,4 @@ - Settings - Django-Components

                  SettingsΒ€

                  You can configure django_components with a global COMPONENTS variable in your Django settings file, e.g. settings.py. By default you don't need it set, there are resonable defaults.

                  To configure the settings you can instantiate ComponentsSettings for validation and type hints. Or, for backwards compatibility, you can also use plain dictionary:

                  # settings.py
                  + Settings - Django-Components      

                  SettingsΒ€

                  You can configure django_components with a global COMPONENTS variable in your Django settings file, e.g. settings.py. By default you don't need it set, there are resonable defaults.

                  To configure the settings you can instantiate ComponentsSettings for validation and type hints. Or, for backwards compatibility, you can also use plain dictionary:

                  # settings.py
                   from django_components import ComponentsSettings
                   
                   COMPONENTS = ComponentsSettings(
                  diff --git a/dev/reference/tag_formatters/index.html b/dev/reference/tag_formatters/index.html
                  index 6f4bc650..0e8202cb 100644
                  --- a/dev/reference/tag_formatters/index.html
                  +++ b/dev/reference/tag_formatters/index.html
                  @@ -1,4 +1,4 @@
                  - Tag formatters - Django-Components      

                  Tag FormattersΒ€

                  Tag formatters allow you to change the syntax for calling components from within the Django templates.

                  Tag formatter are set via the tag_formatter setting.

                  Available tag formattersΒ€

                  ComponentFormatter Β€

                  Bases: django_components.tag_formatter.TagFormatterABC

                  See source code

                  The original django_component's component tag formatter, it uses the {% component %} and {% endcomponent %} tags, and the component name is given as the first positional arg.

                  Example as block:

                  {% component "mycomp" abc=123 %}
                  + Tag formatters - Django-Components      

                  Tag FormattersΒ€

                  Tag formatters allow you to change the syntax for calling components from within the Django templates.

                  Tag formatter are set via the tag_formatter setting.

                  Available tag formattersΒ€

                  ComponentFormatter Β€

                  Bases: django_components.tag_formatter.TagFormatterABC

                  See source code

                  The original django_component's component tag formatter, it uses the {% component %} and {% endcomponent %} tags, and the component name is given as the first positional arg.

                  Example as block:

                  {% component "mycomp" abc=123 %}
                       {% fill "myfill" %}
                           ...
                       {% endfill %}
                  diff --git a/dev/reference/template_tags/index.html b/dev/reference/template_tags/index.html
                  index 238e064f..5944ca8f 100644
                  --- a/dev/reference/template_tags/index.html
                  +++ b/dev/reference/template_tags/index.html
                  @@ -1,4 +1,4 @@
                  - Template tags - Django-Components      

                  Template tagsΒ€

                  All following template tags are defined in

                  django_components.templatetags.component_tags

                  Import as

                  {% load component_tags %}
                  + Template tags - Django-Components      

                  Template tagsΒ€

                  All following template tags are defined in

                  django_components.templatetags.component_tags

                  Import as

                  {% load component_tags %}
                   

                  componentΒ€

                  {% component [arg, ...] **kwargs [only] %}
                   {% endcomponent %}
                   

                  See source code

                  Renders one of the components that was previously registered with @register() decorator.

                  Args:

                  • name (str, required): Registered name of the component to render
                  • All other args and kwargs are defined based on the component itself.

                  If you defined a component "my_table"

                  from django_component import Component, register
                  diff --git a/dev/reference/template_vars/index.html b/dev/reference/template_vars/index.html
                  index 779bfd8c..3fdf77ef 100644
                  --- a/dev/reference/template_vars/index.html
                  +++ b/dev/reference/template_vars/index.html
                  @@ -1,4 +1,4 @@
                  - Template vars - Django-Components      

                  Template variablesΒ€

                  Here is a list of all variables that are automatically available from inside the component's template and in on_render_before / on_render_after hooks.

                  is_filled instance-attribute Β€

                  is_filled: Dict[str, bool]
                  + Template vars - Django-Components      

                  Template variablesΒ€

                  Here is a list of all variables that are automatically available from inside the component's template and in on_render_before / on_render_after hooks.

                  is_filled instance-attribute Β€

                  is_filled: Dict[str, bool]
                   

                  See source code

                  Dictonary describing which component slots are filled (True) or are not (False).

                  New in version 0.70

                  Use as {{ component_vars.is_filled }}

                  Example:

                  {# Render wrapping HTML only if the slot is defined #}
                   {% if component_vars.is_filled.my_slot %}
                       <div class="slot-wrapper">
                  diff --git a/dev/reference/urls/index.html b/dev/reference/urls/index.html
                  index fde1ace3..1c223b6d 100644
                  --- a/dev/reference/urls/index.html
                  +++ b/dev/reference/urls/index.html
                  @@ -1,4 +1,4 @@
                  - Urls - Django-Components      

                  URLsΒ€

                  Below are all the URL patterns that will be added by adding django_components.urls.

                  See Installation on how to add these URLs to your Django project.

                  Django components already prefixes all URLs with components/. So when you are adding the URLs to urlpatterns, you can use an empty string as the first argument:

                  from django.urls import include, path
                  + Urls - Django-Components      

                  URLsΒ€

                  Below are all the URL patterns that will be added by adding django_components.urls.

                  See Installation on how to add these URLs to your Django project.

                  Django components already prefixes all URLs with components/. So when you are adding the URLs to urlpatterns, you can use an empty string as the first argument:

                  from django.urls import include, path
                   
                   urlpatterns = [
                       ...
                  diff --git a/dev/release_notes/index.html b/dev/release_notes/index.html
                  index c3eb997f..bcb20a5d 100644
                  --- a/dev/release_notes/index.html
                  +++ b/dev/release_notes/index.html
                  @@ -1,4 +1,4 @@
                  - Release notes - Django-Components      

                  Release notesΒ€

                  v0.124Β€

                  FeatΒ€

                  • Instead of inlining the JS and CSS under Component.js and Component.css, you can move them to their own files, and link the JS/CSS files with Component.js_file and Component.css_file.

                    Even when you specify the JS/CSS with Component.js_file or Component.css_file, then you can still access the content under Component.js/css - behind the scenes, the content of the JS/CSS files will be set to Component.js/css upon first access.

                    With this change, the role of Component.js/css and the JS/CSS in Component.Media has changed:

                    • The JS/CSS defined in Component.js/css or Component.js/css_file is the "main" JS/CSS
                    • The JS/CSS defined in Component.Media.js/css are secondary or additional

                    See the updated "Getting Started" tutorial

                  RefactorΒ€

                  • The undocumented Component.component_id was removed. Instead, use Component.id. Changes:

                    • While component_id was unique every time you instantiated Component, the new id is unique every time you render the component (e.g. with Component.render())
                    • The new id is available only during render, so e.g. from within get_context_data()
                  • Component's HTML / CSS / JS are now resolved and loaded lazily. That is, if you specify template_name, js_file, css_file, or Media.js/css, the file paths will be resolved only once you:

                    1. Try to access component's HTML / CSS / JS, or
                    2. Render the component.

                    Read more on Accessing component's HTML / JS / CSS.

                  v0.123Β€

                  FixΒ€

                  • Fix edge cases around rendering components whose templates used the {% extends %} template tag (#859)

                  v0.122Β€

                  FeatΒ€

                  v0.121Β€

                  FixΒ€

                  • Fix the use of Django template filters (|lower:"etc") with component inputs #855.

                  v0.120Β€

                  ⚠️ Attention ⚠️ - Please update to v0.121 to fix bugs introduced in v0.119.

                  FixΒ€

                  • Fix the use of translation strings _("bla") as inputs to components #849.

                  v0.119Β€

                  ⚠️ Attention ⚠️ - This release introduced bugs #849, #855. Please update to v0.121.

                  FixΒ€

                  RefactorΒ€

                  v0.118Β€

                  FeatΒ€

                  • Add support for context_processors and RenderContext inside component templates

                  Component.render() and Component.render_to_response() now accept an extra kwarg request.

                  ```py
                  + Release notes - Django-Components      

                  Release notesΒ€

                  v0.124Β€

                  FeatΒ€

                  • Instead of inlining the JS and CSS under Component.js and Component.css, you can move them to their own files, and link the JS/CSS files with Component.js_file and Component.css_file.

                    Even when you specify the JS/CSS with Component.js_file or Component.css_file, then you can still access the content under Component.js/css - behind the scenes, the content of the JS/CSS files will be set to Component.js/css upon first access.

                    With this change, the role of Component.js/css and the JS/CSS in Component.Media has changed:

                    • The JS/CSS defined in Component.js/css or Component.js/css_file is the "main" JS/CSS
                    • The JS/CSS defined in Component.Media.js/css are secondary or additional

                    See the updated "Getting Started" tutorial

                  RefactorΒ€

                  • The undocumented Component.component_id was removed. Instead, use Component.id. Changes:

                    • While component_id was unique every time you instantiated Component, the new id is unique every time you render the component (e.g. with Component.render())
                    • The new id is available only during render, so e.g. from within get_context_data()
                  • Component's HTML / CSS / JS are now resolved and loaded lazily. That is, if you specify template_name, js_file, css_file, or Media.js/css, the file paths will be resolved only once you:

                    1. Try to access component's HTML / CSS / JS, or
                    2. Render the component.

                    Read more on Accessing component's HTML / JS / CSS.

                  v0.123Β€

                  FixΒ€

                  • Fix edge cases around rendering components whose templates used the {% extends %} template tag (#859)

                  v0.122Β€

                  FeatΒ€

                  v0.121Β€

                  FixΒ€

                  • Fix the use of Django template filters (|lower:"etc") with component inputs #855.

                  v0.120Β€

                  ⚠️ Attention ⚠️ - Please update to v0.121 to fix bugs introduced in v0.119.

                  FixΒ€

                  • Fix the use of translation strings _("bla") as inputs to components #849.

                  v0.119Β€

                  ⚠️ Attention ⚠️ - This release introduced bugs #849, #855. Please update to v0.121.

                  FixΒ€

                  RefactorΒ€

                  v0.118Β€

                  FeatΒ€

                  • Add support for context_processors and RenderContext inside component templates

                  Component.render() and Component.render_to_response() now accept an extra kwarg request.

                  ```py
                   def my_view(request)
                       return MyTable.render_to_response(
                           request=request
                  diff --git a/versions.json b/versions.json
                  index 6dc2e6cb..12d20858 100644
                  --- a/versions.json
                  +++ b/versions.json
                  @@ -1,7 +1,7 @@
                   [
                     {
                       "version": "dev",
                  -    "title": "dev (329a398)",
                  +    "title": "dev (b99e32e)",
                       "aliases": []
                     },
                     {