UX FormCollection #90

stakovicz · 2021-05-03T10:05:39Z

Q	A
Bug fix?	no
New feature?	yes
Tickets	Fix #3
License	MIT

Handle form collections, add & remove buttons

weaverryan

I'm super excited that someone has taken this in - it will be a huge win! I have one major comment that discusses direction on this feature. Btw, don't hesitate to ping me in Symfony's slack if you'd like to discuss in real time :)

src/FormCollection/.gitattributes

src/FormCollection/DependencyInjection/FormCollectionExtension.php

src/FormCollection/Form/CollectionType.php

src/FormCollection/README.md

weaverryan · 2021-05-06T14:45:39Z

src/FormCollection/README.md

+```
+You have 2 different themes :
+- `@FormCollection/form_theme_div.html.twig`
+- `@FormCollection/form_theme_table.html.twig`


This is the biggest question make for me with this very nice PR. If we provide a built-in form theme to "rendering everything for them", then we will also need a Bootstrap 4/5 theme... and a tailwind theme. And, if the user needs to customize how things look, then they need to override a fairly complex form theme that we've created here.

I'm not definitely against this. However, I'd like to see if we can document how this new feature could be used if there were no form themes included. For example,

Now that your BlogFormType form set up and with a comments field that is a CollectionType, you can
render it in your template:

{% macro commentFormRow(commentForm) %} <div class="col-4" data-symfony--ux-form-collection--collection-target="entry" > {{ form_errors(commentForm) }} {{ form_row(commentForm.content) }} {{ form_row(commentForm.otherField) }} <a data-action="symfony--ux-form-collection--collection#delete"> Remove </a> </div> {% endblock %} <div class="row" {{ stimulus_controller('symfony/ux-form-collection/collection', { prototype: _self.commentFormRow(form.comments.vars.prototype), }) }} > {% for commentForm in form.comments %} {{ _self.commentFormRow(commentForm) }} {% endfor %} <a data-action="symfony--ux-form-collection--collection#add"> Add Another </a> </div>

This would give me full control over everything, including the buttons. The Stimulus controller would just handle making it all work :). The worst pieces are the super-ugly data-action and data-...-target attributes. But this would look much nicer if we merged symfony/webpack-encore-bundle#124

There may be some other missing pieces... but in theory, this should be enough to work. The "delete" button should not need a data-index-entry attribute, as we can look to its ancestors for the "closest" entry target to know which item is being removed.

So, this is my thinking :). No form theme, but we make it as dead-simple as possible for users to render things themselves.

My idea was to make a component very easy to use.
It's true that template overloading can be complicated due to attributes related to Stimulus.
With these 2 templates (@FormCollection/form_theme_div.html.twig, @FormCollection/form_theme_table.html.twig) we cover a maximum of use cases.

For your proposal, there should be explicit errors when the controller is wrong or the action is not correctly entered.

I think you need to know Stimulus to be able to set up HTML according to the documentation.

To make a better judgement, I'll need some time to play with this in a real project :). Would you be willing/able to push a demo app to GitHub that uses this (with some quick setup instructions)?

Here you have my repo for my test :
https://github.com/stakovicz/ux-collection-test/
Enjoy !

I've made an update.
Now you can use a predefined theme or not.
You have the choice.

I need help to do more tests.

Hi @weaverryan,

Any reason to use a macro instead of a proper form theme here?

The macro forces you to use it everywhere it's needed (eg. prototype & entries as in your example) while a "real" form theme would apply automatically to both.

stakovicz · 2021-05-06T18:59:35Z

Thanks @weaverryan, for taking the time to the review.
I'm intimidated by you because I know you through SymfonyCast ;-)

This is my first contribution, but you are all very kind to help me!

weaverryan · 2021-05-07T13:27:03Z

Thanks @weaverryan, for taking the time to the review.
I'm intimidated by you because I know you through SymfonyCast ;-)

Well, I'm happy to know you know too ;)

This is my first contribution, but you are all very kind to help me!

It's a very big feature for a first contribution - nice work!

tgalopin · 2021-05-08T11:27:12Z

Hi @stakovicz !

Thanks very much for your PR, as Ryan I'm quite excited by this as it's a major requirement for Symfony Forms.

I think, as Ryan mentioned, the only point where I think we need to spend some time thinking is how templates are handled (ie. what HTML is generated). Generally speaking, Symfony as a framework has helpers that generate several HTML tags (like in forms) but usually these helpers become more complex to work with than the original HTML. This was the reasoning behind https://symfony.com/blog/new-in-symfony-5-2-form-field-helpers for instance: use inline attribute helpers instead of tags helpers.

Perhaps your solution is the best, I don't know yet as I didn't have a deep look into it, but it' worth spending some time: it will have a huge impact on developer experience.

I'll have a deeper look asap :) .

stakovicz

Hi @tgalopin!

Thank you for your look.

Indeed, I am divided.
On the one hand, the solution that I propose allows an almost instantaneous use.
On the other hand, your solution is very flexible and allows maximum customization.

You know the community better than I do.
You also have a lot more experience.
I trust you in the final choice and you will follow.

stakovicz · 2021-05-07T19:13:20Z

src/FormCollection/README.md

+                'button_add' => [
+                     // Default text for the add button
+                    'text' => 'Add',    
+                    // Add HTML classes to the add button
+                    'class' => 'btn btn-outline-primary'
+                ],
+                'button_delete' => [
+                    // Default text for the delete button
+                    'text' => 'Remove',    
+                    // Add HTML classes to the add button
+                    'class' => 'btn btn-outline-secondary'
+                ],


@weaverryan I'm not sure how to refactor these defaults values for the same project.
When using an HTML framework, the classes are always the same for buttons (for example).

I'm not sure but have you tried with 2 ButtonType in the Form when the options "allow_add" & "allow_delete" are true?
This would allow to modify their appearance via the twig blocks

@maxhelias allow_add is a boolean type from the original FormType.

src/FormCollection/README.md

jmsche

Hi,

As my knowledge about JavaScript is pretty much not existent, I reviewed the PR but only for PHP, Twig & docs :)

My main goals with this review are (as explained in the review):

Putting the default translations in the Form Type rather than in the templates
Having 4 distinct options with allowed types, instead of two arrays with no types at all
Docs: form theme instead of macros

Thanks for your PR! :)

src/FormCollection/Form/UXCollectionType.php

src/FormCollection/README.md

src/FormCollection/Resources/views/form_theme_div.html.twig

src/FormCollection/Resources/views/form_theme_table.html.twig

zmitic · 2021-06-05T12:29:07Z

@stakovicz
First I want to thank you for doing this. I have projects with deeply nested collections, this addition is more than welcome,

I have one question about the problem I encountered few times and suggested jquery.collection plugin suffered from it; I had to make my own implementation because of that.

TL;DR
Will it be possible to affect how the index is increased in this line?

Or better: a way to set base index not as the number of existing, but for example seconds since Unix epoch?

Reason, click to expand

Imagine editing (create is not a problem) a form with a collection that has 3 Users.

So Symfony renders them with keys 0, 1, 2.

Now you delete all of them and add new User. Submitted array to the server will only have key 3; so far it is good, Symfony knows you deleted first 3 and added new one.

Here comes the problem. Validation fails and the form is rendered again, with that one user (the new one). You add 2 new users but instead of creating keys 4 and 5, the suggested Symfony plugin will reset keys.

The problem is that now backend will think that data has been updated (because submitted keys are the same as when form was first created), and not know that old users were deleted and new ones were created.

Keys are very important here; default mapper is sort-of doing some bypass by searching for objects (mostly entities) but I have more extreme cases.

I solved it by making the base index not to be the count of existing elements, but the seconds of the current time. Submitted data has big keys but no problem since that.

Any thoughts?

stakovicz · 2021-06-06T09:53:33Z

@zmitic

First I want to thank you for doing this. I have projects with deeply nested collections, this addition is more than welcome,

Thanks a lot !

...
Any thoughts?

OK I see the problem. I watch what I can do.

stakovicz · 2021-06-06T11:58:09Z

@zmitic this commit allow you to set the default index :
8b23e78

The value is set automatically if you use a predefined theme.

zmitic · 2021-06-06T19:04:06Z

@stakovicz Perfect! I will find a way to override it, still didn't figure that for Stimulus.

Thank you.

stakovicz · 2021-06-11T13:22:42Z

@weaverryan @tgalopin do you have any feedback ?

jorismak · 2021-06-18T15:45:17Z

To be honest, I tried making - ahem, for my self - some re-usable javascript code to handle Collections.
But every time I try to use it, my use case for a Collection is slightly different, and I end up customizing a lot anyway.

The HTML changes per project (sometimes only widgets in a table, sometimes a 'normal' bootstrap horizontal form, then again something different, then the keys are numeric and have no meaning, then the keys are identifiers which need to be precise, etc...).

Now aboard the Stimulus hype-train, I have a simple 'collection_controller' that handles the add-button and delete-button code. With a delete-button with a data-action= attribute and a simple data-remove-key= attribute, I have enough that all my everytime-it-is-slightly-different templates can work.

I make a macro that handles a single child of the collection. That macro is then also usable to render a prototype string (simply calling the macro in an html-attribute will escape it properly) and for me it's easier to write a small template for the collection-at-hand then try to make a 'one size fits all template'.

So personally, I wouldn't bother with trying to come up with some template-style that fits all... because it never will in my experience.

Include a 'simple' piece of form theme that uses existing form_row() and form_label() so that it is as generic as possible, but make sure the stimulus controller doesn't depend on it hard. And include a little bit of 'demo' template for people whishing to do it their way.

This way Symfony has - ahem, finally - working out-of-the-box javascript for Collections :), but it's still easy enough for people who know how to customize a collection to use a partial-twig as form-theme and just render it there how they see fit.

ker0x

Thanks @stakovicz for this work. I have taken inspiration from what you did to build my own custom collection type with some improvements.

I also made some feedback 😉

For those who are interested, here is a gist of my current implementation: https://gist.github.com/ker0x/8a1bad79a22f0ebae9ddf28c264dd13f

src/FormCollection/Resources/views/form_theme_div.html.twig

src/FormCollection/Resources/views/form_theme_table.html.twig

ker0x · 2021-07-20T12:44:55Z

src/FormCollection/Form/UXCollectionType.php

+    {
+        $resolver->setDefaults([
+            'button_add_text' => 'Add',
+            'button_add_class' => '',


I will renamed this key button_add_attr to allow user to set multiple attributes to the Add button and use the attribute block available in the form_theme to build them. Same for the button_delete_class

Can you add support for arrays as well here: https://gist.github.com/ker0x/8a1bad79a22f0ebae9ddf28c264dd13f#file-enhancedcollectiontype-php-L42-L44

Indeed it's better, gist updated! Thanks 😉

seb-jean · 2021-09-16T13:38:26Z

I am interested :)

seb-jean · 2021-09-17T09:56:57Z

Hi,

With example below, data-ux-form-collection-prototype-value is badly encoded because there is html_attr on value : https://github.com/symfony/webpack-encore-bundle/blob/main/src/Twig/StimulusTwigExtension.php#L69

{% macro commentFormRow(commentForm) %}
    <div
        class="col-4"
        data-symfony--ux-form-collection--collection-target="entry"
    >
        {{ form_errors(commentForm) }}
        {{ form_row(commentForm.content) }}
        {{ form_row(commentForm.otherField) }}

        <a data-action="symfony--ux-form-collection--collection#delete">
            Remove
        </a>
    </div>
{% endblock %}

<div
    class="row"
    {{ stimulus_controller('symfony/ux-form-collection/collection', {
        prototype: _self.commentFormRow(form.comments.vars.prototype),
    }) }}
>
    {% for commentForm in form.comments %}
        {{ _self.commentFormRow(commentForm) }}
    {% endfor %}

    <a data-action="symfony--ux-form-collection--collection#add">
        Add Another
    </a>
</div>

From UXCollectionType to the view

Co-authored-by: jmsche <[email protected]>

Co-authored-by: Romain Monteil <[email protected]>

tgalopin · 2021-11-24T21:20:14Z

Hello @stakovicz

Sorry for the delayed answer, I didn't have much time to work on UX lately. I plan to spend more time on it in the coming weeks.

As Ryan explained, I think we need to find a way to tackle the templating, especially for custom needs. I'll have a look at your example repository and see if there are interesting ideas we could have.

alexander-schranz

Would really like to see something like this in the symfony/ux component. Would just look that add and remove buttons are rendered using symfony form theme. I added a few comments about it.

/cc @weaverryan @tgalopin what do you think about them?

src/FormCollection/README.md

alexander-schranz · 2022-01-17T16:08:37Z

src/FormCollection/Resources/views/form_theme_div.html.twig

@@ -0,0 +1,52 @@
+{%- block button_add -%}
+    {%- set attrDataAction = (attr['data-action']|default('') ~ ' ' ~ controllerName ~ '#add')|trim -%}
+    <button data-action="{{ attrDataAction }}"


Would be better if we can use the exist button_widget block:

https://github.com/symfony/symfony/blob/41697e78a158156952f8c445512f11bd58f90958/src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig#L224

Maybe we can use in the Form Builder the ButtonType and then give it also a special block_prefix so we can go with collection_button_add_widget to overwrite it.

So we could go with:

'button_add_options => [ 'label' => 'app.button_add', 'label_translation_parameters' => [], 'attr' => ['class' => '...'] ],

This make it possible to use any of the exist button options and would be easier for theming also for future themes.

Yea, this is interesting. To accomplish this, I think it would be very similar to how prototype is done, which is sort of a "fake field" that is added to the form... without being a real field.

You can see how the prototype is created in buildForm()... but not actually added to the field: https://github.com/symfony/symfony/blob/a05702965e9fc0de7ce77d1641e772e2fbfe9911/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L39-L40

Later, it's added as a view variable: https://github.com/symfony/symfony/blob/a05702965e9fc0de7ce77d1641e772e2fbfe9911/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L91-L101

It would be interesting to do the same thing with both buttons. We would pass button_add_options directly to the $builder->create() call - e.g. how prototype_options are passed here: https://github.com/symfony/symfony/blob/a05702965e9fc0de7ce77d1641e772e2fbfe9911/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L33

alexander-schranz · 2022-01-17T16:21:51Z

src/FormCollection/Resources/views/form_theme_table.html.twig

+    <div data-controller="{{ dataController }}"
+         data-{{ controllerName }}-allow-add-value="{{ allow_add|json_encode }}"
+         data-{{ controllerName }}-allow-delete-value="{{ allow_delete|json_encode }}"
+         data-{{ controllerName }}-button-add-value="{{ block('button_add')|e('html_attr') }}"


Think we should go here with form_widget(button_add_prototype).

We can create the button add prototype this way:

// build form $prototype = $builder->create('button_add', ButtonType, array_merge(['block_prefix' => 'collection_add_button'], $options['button_add_options'])); $builder->setAttribute('button_add_prototype', $prototype->getForm()); // build view if ($form->getConfig()->hasAttribute('button_add_prototype')) { $prototype = $form->getConfig()->getAttribute('button_add_prototype'); $view->vars['button_add_prototype'] = $prototype->setParent($form)->createView($view); }

This is similar how the prototype of the collection itself is created:

https://github.com/symfony/symfony/blob/41697e78a158156952f8c445512f11bd58f90958/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L39-L40

https://github.com/symfony/symfony/blob/6.1/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L64-L67

This way we make sure the button using the form theme and we can use button_widget or collection_add_button_widget to overwrite it the Theme way of symfony forms.

alexander-schranz · 2022-01-17T16:23:02Z

src/FormCollection/Resources/views/form_theme_table.html.twig

+    {% set startIndex = indexKeys|length == 0 ? 0 : max(indexKeys) %}
+
+    <div data-controller="{{ dataController }}"
+         data-{{ controllerName }}-allow-add-value="{{ allow_add|json_encode }}"


I find -allow-add-value and button-add-value confusing. I think I would just go with button-add-prototype. If it is set there is add if not there is no add else it could be confusing that I can set the prototype but its not used.

What I'm personally missing is a -button-remove-target-selector. So I can adjust were the ux javascript will render target the button.

mario-fehr · 2022-04-10T12:36:36Z

@stakovicz any progress on this to finish it? Would love to use this.

weaverryan · 2022-05-06T14:18:39Z

I like @alexander-schranz's ideas, and I think if we can implement those, I would support this. @stakovicz you've done a lot of great work on this, but we've been slow to review. Are you still able/interested to finish this?

Thx :)

stakovicz · 2022-05-06T17:54:33Z

Yes, I'm in !
I think can do the last changes.

weaverryan

Hey @stakovicz!

I just had an opportunity to put this to the test on a local project - I really enjoyed it! I like how you have built both an automatic feature (just render the "form row" and everything is added automatically) but also an "escape hatch" where you can render all of the part of the collection field manually, but still take advantage of the Stimulus controller.

I've left some feedback: I think we just need to smooth out some technical details and this will be ready. I'm really excited for it :).

Cheers!

weaverryan · 2022-05-23T18:05:08Z

src/FormCollection/composer.json

+        "symfony/framework-bundle": "^4.4.17|^5.0",
+        "symfony/phpunit-bridge": "^5.2",
+        "symfony/twig-bundle": "^4.4.17|^5.0",
+        "symfony/var-dumper": "^4.4.17|^5.0"


These should all be updated to ^5.4|^6.0

weaverryan · 2022-05-23T18:10:14Z

src/FormCollection/composer.json

+        ]
+    },
+    "require": {
+        "php": ">=7.2.5",


Change to "php": ">=8.0", and then we can update code accordingly (e.g. using property promotion, etc). We could even bump to 8.1 if necessary, but it looks like you got things working on 7.2, so 8.0 should, hopefully, be easy enough :).

weaverryan · 2022-05-23T18:29:09Z

src/FormCollection/README.md

@@ -0,0 +1,190 @@
+# UX Form Collection


We're now doing this as an index.rst file. So, it just needs to move, then convert to RST

I don't see any RST files in the other parts 🤨. They are all in .md

Your branch may be a little out-of-date, see eg. https://github.com/symfony/ux/tree/2.x/src/Chartjs/Resources/doc

Thanks, I had not looked in this file 😬

weaverryan · 2022-05-23T18:30:38Z

src/FormCollection/README.md

@@ -0,0 +1,190 @@
+# UX Form Collection
+
+Symfony UX Form collection is a Symfony bundle providing light UX for collection


Suggested change

Symfony UX Form collection is a Symfony bundle providing light UX for collection

Symfony UX Form collection is a Symfony bundle providing JavaScript-powered "add" and "remove"

buttons to your `CollectionType` fields.

It'd be GREAT to have a little screenshot :)

weaverryan · 2022-05-23T18:32:15Z

src/FormCollection/README.md

+
+## Use predefined theme
+
+You need to select the right theme from the one you are using:


Suggested change

You need to select the right theme from the one you are using:

First, choose a form theme to use for styling your collection type:

weaverryan · 2022-05-23T20:16:23Z

src/FormCollection/README.md

+
+[Check the Symfony doc](https://symfony.com/doc/4.4/form/form_themes.html) for the different ways to set themes in Symfony.
+
+## Use a custom form theme


Let's move this section down, below Usage. And we can call it: Customizing how the Field Renders.

weaverryan · 2022-05-23T20:17:30Z

src/FormCollection/README.md

+    {{ form_row(comments) }}
+    {# ... #}
+{{ form_end(form) }}
+```


Somewhere, we need to mention that, in order for this to work, they likely need orphanRemoval and cascade=['persist'] on their entities. This is what my field looks like:

#[ORM\OneToMany(mappedBy: 'directory', targetEntity: File::class, orphanRemoval: true, cascade: ['persist'])] private $files;

weaverryan · 2022-05-23T20:19:23Z

src/FormCollection/README.md

+    {
+        $builder
+            // ...
+            ->add('comments', UXCollectionType::class, [


To be as helpful as possible, I think we need to show the user a simple CommentType class. And then, use that here with 'entry_type' => CommentType::class`.

Overall, this is how my example looks locally - I think these options are helpful to all show!

'allow_add' => true, 'allow_delete' => true, 'entry_type' => FileType::class, // ideally UXCollectionType can set this for us 'by_reference' => false, 'entry_options' => [ // hides the "0", "1", "2" labels on the embedded forms 'label' => false, ], 'button_add_options' => [ 'label' => '<span class="fa fa-plus"></span>', 'label_html' => true, 'class' => 'btn btn-secondary btn-sm' ], 'button_delete_options' => [ 'label' => '<span class="fa fa-times"></span>', 'label_html' => true, 'class' => 'btn btn-danger btn-sm' ],

weaverryan · 2022-05-23T20:24:17Z

src/FormCollection/Resources/views/form_theme_div.html.twig

@@ -0,0 +1,52 @@
+{%- block button_add -%}
+    {%- set attrDataAction = (attr['data-action']|default('') ~ ' ' ~ controllerName ~ '#add')|trim -%}
+    <button data-action="{{ attrDataAction }}"


Yea, this is interesting. To accomplish this, I think it would be very similar to how prototype is done, which is sort of a "fake field" that is added to the form... without being a real field.

You can see how the prototype is created in buildForm()... but not actually added to the field: https://github.com/symfony/symfony/blob/a05702965e9fc0de7ce77d1641e772e2fbfe9911/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L39-L40

Later, it's added as a view variable: https://github.com/symfony/symfony/blob/a05702965e9fc0de7ce77d1641e772e2fbfe9911/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L91-L101

It would be interesting to do the same thing with both buttons. We would pass button_add_options directly to the $builder->create() call - e.g. how prototype_options are passed here: https://github.com/symfony/symfony/blob/a05702965e9fc0de7ce77d1641e772e2fbfe9911/src/Symfony/Component/Form/Extension/Core/Type/CollectionType.php#L33

weaverryan · 2022-05-23T20:25:05Z

src/FormCollection/README.md

+{% macro commentFormRow(commentForm) %}
+    <div
+        class="col-4"
+        data-symfony--ux-form-collection--collection-target="entry"


We should show {{ stimulus_controller() }} here, and {{ stimulus_action() }} and `{{ stimulus_target() }} in the other places.

weaverryan · 2022-05-23T23:48:05Z

src/FormCollection/Resources/views/form_theme_div.html.twig

+    >
+        {%- if form is rootform -%}
+            {{ form_errors(form) }}
+        {%- endif -%}


What's this for?

weaverryan · 2022-05-24T15:34:52Z

src/FormCollection/Resources/assets/src/controller.ts

+        if (this.allowAddValue) {
+            // Add button Add
+            const buttonAdd = this._textToNode(this.buttonAddValue);
+            this.element.prepend(buttonAdd);


I think this should actually be added to the bottom. In the future, we may make it configurable, bottom seems like a better default to me.

weaverryan · 2022-06-20T17:00:04Z

Friendly ping - let us know if and how we can help, or if anything is unclear :)

stakovicz · 2022-06-20T19:41:04Z

Good evening Ryan,

Thanks for the reminder, everything is clear.
However, at the moment, I can't find time for this project.

If you wish, you can continue.

Best regards,

weaverryan · 2022-07-08T14:59:11Z

Totally understandable :). If anyone else wants to continue this PR, please feel free to take this code, build on top of it, and submit a new PR. I would like it to be finished - it's a very nice idea.

alexander-schranz · 2022-07-18T19:26:52Z

I'm currently trying based on this implement and the feedback trying to implemented a new variation of the UXCollectionType which does not requiring even .html.twig to solve also the comment about the overwrite the collection_widget block.

I'm nearly there to remove all .html.twig and set all required attributes and even the buttons inside the form types. I sadly has one thing I could not yet solve and that is I need to wrap the entry_type to add the remove button there, for this I'm doing the following in the UXCollectionType:

$entryTypeNormalizer = function (OptionsResolver $options, $value) {
   return UXCollectionEntryType::class; // overwrite the given entry_point with wrapped component
};

$entryOptionsNormalizer = function (OptionsResolver $options, $value) {
    return [
        'entry_type' => $options['entry_type'], // TODO get the original entry_type here
        'entry_options' => $value, // forwards options
    ];
};

$resolver->addNormalizer('entry_type', $entryTypeNormalizer);
$resolver->addNormalizer('entry_options', $entryOptionsNormalizer);

The problem is I'm loosing the original given 'entry_type' option this way. Which I need to forward to my UXCollectionEntryType. Sure we could go with ux_entry_type as option but that would in my case be a bad developer experience. So is there any way we get the original value here or somebody have another idea here?

weaverryan reviewed May 6, 2021

View reviewed changes

stakovicz commented May 8, 2021

View reviewed changes

jmsche reviewed May 23, 2021

View reviewed changes

ker0x reviewed Jul 20, 2021

View reviewed changes

stakovicz and others added 15 commits November 6, 2021 20:56

UX FormCollection

ae5d325

Remove hard coded property_name __name__

c305f0c

PHP CS Fixer

5e6dd84

First jests

eea2313

Rename CollectionType > UXCollectionType

f651d90

Rename CollectionType > UXCollectionType

cc02076

DependencyInjection Clean

dceb2cf

Fix .gitattributes

dfb54f8

Move default values

9300cda

From UXCollectionType to the view

Predefined theme or not

ec4342a

Update src/FormCollection/README.md

b4f40cd

Co-authored-by: jmsche <[email protected]>

Update src/FormCollection/README.md

0584757

Co-authored-by: jmsche <[email protected]>

Update src/FormCollection/README.md

abd2b8f

Co-authored-by: jmsche <[email protected]>

Update src/FormCollection/Resources/views/form_theme_div.html.twig

3996f3b

Co-authored-by: jmsche <[email protected]>

Update src/FormCollection/README.md

aaa6811

Co-authored-by: jmsche <[email protected]>

stakovicz and others added 2 commits November 6, 2021 20:56

Update src/FormCollection/Resources/views/form_theme_table.html.twig

94be94c

Co-authored-by: Romain Monteil <[email protected]>

Update src/FormCollection/Resources/views/form_theme_table.html.twig

c805c0e

Co-authored-by: Romain Monteil <[email protected]>

stakovicz force-pushed the main branch from f8e29af to c805c0e Compare November 6, 2021 19:56

stakovicz added 2 commits November 6, 2021 21:04

Fix coding-style-js

e56d04b

Prettier

7467cee

alexander-schranz reviewed Jan 17, 2022

View reviewed changes

alexander-schranz mentioned this pull request Jan 17, 2022

Fix composer json name stakovicz/ux-collection#3

Merged

Merge branch 'symfony:2.x' into main

a8c730c

stakovicz and others added 4 commits May 7, 2022 14:03

Merge branch 'symfony:2.x' into main

ecd774a

Rebase and refresh the code

25d8306

fix TU

8e5cd8a

change buttons attr

3b110f9

stakovicz force-pushed the main branch from 02f53ea to 3b110f9 Compare May 22, 2022 08:07

weaverryan reviewed May 23, 2022

View reviewed changes

weaverryan mentioned this pull request May 24, 2022

[LiveComponent] Add a generic LiveCollectionType #324

Merged

4 tasks

weaverryan reviewed May 24, 2022

View reviewed changes

Merge branch 'symfony:2.x' into main

c36157c

alexander-schranz mentioned this pull request Jul 18, 2022

Add ux collection type component #397

Draft

8 tasks

dunglas mentioned this pull request Jul 18, 2022

Add Collection component #398

Draft

2 tasks

alexander-schranz mentioned this pull request Jul 19, 2022

Add Collection component as form type extension #400

Draft

13 tasks

stakovicz closed this Nov 5, 2023

		@@ -0,0 +1,190 @@
		# UX Form Collection

		Symfony UX Form collection is a Symfony bundle providing light UX for collection

	Symfony UX Form collection is a Symfony bundle providing light UX for collection
	Symfony UX Form collection is a Symfony bundle providing JavaScript-powered "add" and "remove"
	buttons to your `CollectionType` fields.


		## Use predefined theme

		You need to select the right theme from the one you are using:

	You need to select the right theme from the one you are using:
	First, choose a form theme to use for styling your collection type:


		[Check the Symfony doc](https://symfony.com/doc/4.4/form/form_themes.html) for the different ways to set themes in Symfony.

		## Use a custom form theme

Uh oh!

UX FormCollection #90

UX FormCollection #90

Uh oh!

Conversation

stakovicz commented May 3, 2021

Uh oh!

weaverryan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stakovicz commented May 6, 2021

Uh oh!

weaverryan commented May 7, 2021

Uh oh!

tgalopin commented May 8, 2021

Uh oh!

stakovicz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maxhelias May 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jmsche left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

zmitic commented Jun 5, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stakovicz commented Jun 6, 2021

Uh oh!

stakovicz commented Jun 6, 2021

Uh oh!

zmitic commented Jun 6, 2021

Uh oh!

stakovicz commented Jun 11, 2021

Uh oh!

jorismak commented Jun 18, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ker0x left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

maxhelias May 8, 2021 •

edited

Loading

zmitic commented Jun 5, 2021 •

edited

Loading

jorismak commented Jun 18, 2021 •

edited

Loading

ker0x Jul 20, 2021 •

edited

Loading