[Admin] Add page to create products #5329

waiting-for-dev · 2023-08-10T07:48:12Z

No description provided.

This component is used to render a text field in a form. It leverages the `type` attribute to also render different input fields, although we might want to specialize in the future. It comes in three sizes: small, medium and large. It also supports rendering a label and a hint, as well as field error messages. It needs to be rendered in the context of a block yielded by one of Rails' form helpers, such as `form_for` or `form_with`. This is to leverage the automatic inferrence of the `name`, `id` and `for` attributes, therefore avoiding boilerplate. When the given form builder is bound to a model instance, the error messages will be automatically extracted. Otherwise, an explicit errors hash needs to be passed. Ref. solidusio#5329

As the logic and styling for the associated label, hint and error messages are the same as for the text_field component, we extract it into a couple of new components: one for the label and one for the guidance (hint and error messages). These new components are marked as private, as they are not meant to be used directly (at least for now). The original text_field component and the new text_area compose the new components but keep the responsibility of how to render the form inputs and which classes or attributes to use. We consider this approach more flexible than, for instance, using inheritance. Although it requires more code than just sharing a bunch of common styles, we keep them decoupled so they can change independently. We stop short of creating another form element component wrapping new extracted pure input and textarea components. We can do that in the future if we need to. Ref. solidusio#5329

We'll need the same logic in the product forms, so we need to extract it to a component. Ref. solidusio#5329

As the logic and styling for the associated label, hint and error messages are the same as for the text_field component, we extract it into a couple of new components: one for the label and one for the guidance (hint and error messages). These new components are marked as private, as they are not meant to be used directly (at least for now). The original text_field component and the new text_area compose the new components but keep the responsibility of how to render the form inputs and which classes or attributes to use. We consider this approach more flexible than, for instance, using inheritance. Although it requires more code than just sharing a bunch of common styles, we keep them decoupled so they can change independently. We stop short of creating another form element component wrapping new extracted pure input and textarea components. We can do that in the future if we need to. Ref. solidusio#5329

We'll need the same logic in the product forms, so we need to extract it to a component. Ref. solidusio#5329

The fieldset component just wraps a group of fields (or, actually, any content) within a fieldset tag. It optionally accepts a legend text and a toggletip component. Ref. solidusio#5329

Introducing a form component brings a two-fold benefit: 1. It wraps all the form component dependencies in a single place so that we don't need to redeclare them in every other form (e.g., the product creation form). 2. It allows defining a form from the outside, which is a first step towards making the admin forms configurable. Internally, it uses Rails' `form_with` helper [1], and all the given arguments are passed to it. The only exception is the `elements:` key, which is used to define the form elements. The form elements are simple builders of renderable things that happen within a form context. That's to say, to be rendered, both the form component instance and the Rails' form builder are given to a `#call` method. We ship with out-of-the-box form elements for fields, fieldsets and arbitrary components or HTML. Notice that there's a circular dependency between form and form elements. While the form calls the elements to get the renderable content, the elements can use the form to get the configured dependencies. For instance, when rendering a text field element, it'll use the configured text_field dependency in the form. This complexity is an acceptable trade-off for a double benefit: the ability to change all the form dependencies at once (e.g., using a different text field component across a form), and the removal of boilerplate from the form element definitions. Nonetheless, the default behavior can be overridden by passing a different component to the form element. This commit also makes some tangential changes that were necessary: - We rename the `form:` parameter to `builder:` in the components within the form namespace. As we have now a form component, that makes it more explicit that it corresponds to the Rails' form builder. - We add `.rb` files within the preview directories to Tailwind watchable files. - We modify the `mock_component` test helper to accept not providing a block. [1] - https://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_with Ref. solidusio#5329

Introducing a form component brings a two-fold benefit: 1. It wraps all the form component dependencies in a single place so that we don't need to redeclare them in every other form (e.g., the product creation form). 2. It allows defining a form from the outside, which is a first step towards making the admin forms configurable. Internally, it uses Rails' `form_with` helper [1], and all the given arguments are passed to it. The only exception is the `elements:` key, which is used to define the form elements. The form elements are simple builders of renderable things that happen within a form context. That's to say, to be rendered, both the form component instance and the Rails' form builder are given to a `#call` method. We ship with out-of-the-box form elements for fields, fieldsets and arbitrary components or HTML. Notice that there's a circular dependency between form and form elements. While the form calls the elements to get the renderable content, the elements can use the form to get the configured dependencies. For instance, when rendering a text field element, it'll use the configured text_field dependency in the form. This complexity is an acceptable trade-off for a double benefit: the ability to change all the form dependencies at once (e.g., using a different text field component across a form), and the removal of boilerplate from the form element definitions. Nonetheless, the default behavior can be overridden by passing a different component to the form element. Having access to the form component is also used by the fieldset element to render the nested elements. This commit also makes some tangential changes that were necessary: - We rename the `form:` parameter to `builder:` in the components within the form namespace. As we have now a form component, that makes it more explicit that it corresponds to the Rails' form builder. - We add `.rb` files within the preview directories to Tailwind watchable files. - We modify the `mock_component` test helper to accept not providing a block. [1] - https://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_with Ref. solidusio#5329

As with the other form components, it's design to be used along a Rails' form builder instance. We need to use Javascript to style the select box differently when the prompt option is the one selected. Ref. solidusio#5329

Introducing a form component brings a two-fold benefit: 1. It wraps all the form component dependencies in a single place so that we don't need to redeclare them in every other form (e.g., the product creation form). 2. It allows defining a form from the outside, which is a first step towards making the admin forms configurable. Internally, it uses Rails' `form_with` helper [1], and all the given arguments are passed to it. The only exception is the `elements:` key, which is used to define the form elements. The form elements are simple builders of renderable things that happen within a form context. That's to say, to be rendered, both the form component instance and the Rails' form builder are given to a `#call` method. We ship with out-of-the-box form elements for fields, fieldsets and arbitrary components or HTML. Notice that there's a circular dependency between form and form elements. While the form calls the elements to get the renderable content, the elements can use the form to get the configured dependencies. For instance, when rendering a text field element, it'll use the configured text_field dependency in the form. This complexity is an acceptable trade-off for a double benefit: the ability to change all the form dependencies at once (e.g., using a different text field component across a form), and the removal of boilerplate from the form element definitions. Nonetheless, the default behavior can be overridden by passing a different component to the form element. Having access to the form component is also used by the fieldset element to render the nested elements. This commit also makes some tangential changes that were necessary: - We rename the `form:` parameter to `builder:` in the components within the form namespace. As we have now a form component, that makes it more explicit that it corresponds to the Rails' form builder. - We add `.rb` files within the preview directories to Tailwind watchable files. - We modify the `mock_component` test helper to accept not providing a block. [1] - https://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_with Ref. solidusio#5329

This component is used to render a text field in a form. It leverages the `type` attribute to also render different input fields, although we might want to specialize in the future. It comes in three sizes: small, medium and large. It also supports rendering a label and a hint, as well as field error messages. It needs to be rendered in the context of a block yielded by one of Rails' form helpers, such as `form_for` or `form_with`. This is to leverage the automatic inferrence of the `name`, `id` and `for` attributes, therefore avoiding boilerplate. When the given form builder is bound to a model instance, the error messages will be automatically extracted. Otherwise, an explicit errors hash needs to be passed. Ref. #5329

As the logic and styling for the associated label, hint and error messages are the same as for the text_field component, we extract it into a couple of new components: one for the label and one for the guidance (hint and error messages). These new components are marked as private, as they are not meant to be used directly (at least for now). The original text_field component and the new text_area compose the new components but keep the responsibility of how to render the form inputs and which classes or attributes to use. We consider this approach more flexible than, for instance, using inheritance. Although it requires more code than just sharing a bunch of common styles, we keep them decoupled so they can change independently. We stop short of creating another form element component wrapping new extracted pure input and textarea components. We can do that in the future if we need to. Ref. #5329

We'll need the same logic in the product forms, so we need to extract it to a component. Ref. #5329

The fieldset component just wraps a group of fields (or, actually, any content) within a fieldset tag. It optionally accepts a legend text and a toggletip component. Ref. #5329

As with the other form components, it's design to be used along a Rails' form builder instance. We need to use Javascript to style the select box differently when the prompt option is the one selected. Ref. #5329

Introducing a form component brings a two-fold benefit: 1. It wraps all the form component dependencies in a single place so that we don't need to redeclare them in every other form (e.g., the product creation form). 2. It allows defining a form from the outside, which is a first step towards making the admin forms configurable. Internally, it uses Rails' `form_with` helper [1], and all the given arguments are passed to it. The only exception is the `elements:` key, which is used to define the form elements. The form elements are simple builders of renderable things that happen within a form context. That's to say, to be rendered, both the form component instance and the Rails' form builder are given to a `#call` method. We ship with out-of-the-box form elements for fields, fieldsets and arbitrary components or HTML. Notice that there's a circular dependency between form and form elements. While the form calls the elements to get the renderable content, the elements can use the form to get the configured dependencies. For instance, when rendering a text field element, it'll use the configured text_field dependency in the form. This complexity is an acceptable trade-off for a double benefit: the ability to change all the form dependencies at once (e.g., using a different text field component across a form), and the removal of boilerplate from the form element definitions. Nonetheless, the default behavior can be overridden by passing a different component to the form element. Having access to the form component is also used by the fieldset element to render the nested elements. This commit also makes some tangential changes that were necessary: - We rename the `form:` parameter to `builder:` in the components within the form namespace. As we have now a form component, that makes it more explicit that it corresponds to the Rails' form builder. - We add `.rb` files within the preview directories to Tailwind watchable files. - We modify the `mock_component` test helper to accept not providing a block. [1] - https://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_with Ref. #5329