Update filter js

[onEXHovia]

Subject

Need #2870
Part #7156, #7158
Migrate from jquery to vanilla(stimulus) js

Changelog

### Changed
- Migrate filter to vanilla js

[onEXHovia]

I don't like this, we could do this on the backend.

[VincentLanglet]

Eslint rules are updated you might try to rebase

[onEXHovia]

@VincentLanglet any idias why failed ci?

[VincentLanglet]

Every time you modify js files you have to update the build and commit it.

npx encore production

[VincentLanglet]

Thanks, can you udpate the changelog you kept the template

### Added
- Some `Class::newMethod()` to do great stuff

Also, ping @jordisala1991 if you want to review.

I think after all the JS-Pr merged, releasing a beta-release might be safer (?).
Or we will need some people to try the 4.x-dev branch after the merge (I don't use sonata anymore...)

[onEXHovia]

There will be a lot of changes. And some with mini BC as #8232 or next pr with remove jquery.scrollto after update SonataPage because he use plugin. IMHO it is better to small releases and get feedback than one big one.

[VincentLanglet]

There will be a lot of changes. And some with mini BC as #8232 or next pr with remove jquery.scrollto after update SonataPage because he use plugin. IMHO it is better to small releases and get feedback than one big one.

Sure I can make more release. I just would like to avoid using user as feedback for BC-break/bugs and having some beta testers since I cannot test this bundle anymore.

If you or someone else has a big enough projet and target 4.x-dev without any issue before next releases ; it's good enough for me to release it.

I'm currently unsure about

• How good the js is tested (I'm not sure it is at all)
• How you try your changes (do you target your branch in your projet ?)

[onEXHovia]

• How you try your changes (do you target your branch in your projet ?)

yes, I am testing on a large project, we have been using sonata it for many years.

[VincentLanglet]

I wonder if it's not safer to keep the sonata-filter-count in case someone use it for css or query selector.

It not an issue to keep some unused classes, no ?

[onEXHovia]

I wonder if it's not safer to keep the sonata-filter-count in case someone use it for css or query selector.

It not an issue to keep some unused classes, no ?

This class was used only in binding js, I have not a special opinion on this, but if you think about it this way, then any change on the frontend, even a change in the nesting of tags, will be a kind of BC for css.

If necessary, let's revert class, fine to me.

[core23]

I haven't used stimulus that much, but we should add a vendor prefix here so it won't clash wish other "list_filter" controller.

[VincentLanglet]

Indeed, we should use sonata- prefix in the safe way we're prefixing twig function with sonata_ https://github.com/sonata-project/SonataAdminBundle/blob/4.x/src/Twig/Extension/SonataAdminExtension.php#L43

[onEXHovia]

by default controller registration is automatic based on file name, file name filter_controller.js matches filter controller in app. We can name the file sonata_filter_controller.js or use manual registration

import { Application } from '@hotwired/stimulus'

import FilterController from '/controllers/filter'

window.Stimulus = Application.start();
Stimulus.register('sonata-filter', FilterController);

if use manual registration, the structure folder could be

contollers/
- filter.js
- filter_list.js
- revision.js
- treeview.js
- confirm_exit.js

IMHO this looks nicer than using auto registration.

[core23]

Symfony is using a @symfony/ prefix for all components:
https://symfony.com/bundles/StimulusBundle/current/index.html#with-webpackencorebundle

Following that guide, we should use something like this:

{{ stimulus_controller('@sonata-project/admin/filter-list', { //...

[onEXHovia]

yeah, with this approach, using outles will be one big pain hotwired/stimulus#641

[onEXHovia]

ok, let's use defaults registration and events as communications between controllers, because to use outlets looks crazy with this approach

export default class extends Controller {
  static outlets = ['symfony--ux-chartjs--chart'];
  connect() { this.symfonyUxChartjsChartOutlet.method() }

[onEXHovia]

Symfony is using a @symfony/ prefix for all components: https://symfony.com/bundles/StimulusBundle/current/index.html#with-webpackencorebundle

Following that guide, we should use something like this:

{{ stimulus_controller('@sonata-project/admin/filter-list', { //...

after reading the documentation and https://github.com/symfony/stimulus-bridge I don't see how stimulus-bridge in current configuration resolve name like {{ stimulus_controller('@sonata-project/admin/filter-list', { //... other than subdirectories or manual registration, any thoughts and ideas are welcome.

[core23]

For what have worked on my projects, you need to add this to the package.json:

{
    "name": "@sonata-project/admin-bundle",
    "symfony": {
        "controllers": {
            "filter": {
                "main": "dist/calendar.controller.js",
                "fetch": "lazy",
                "enabled": true,
                "autoimport": {
                    "@sonata-project/admin-bundle/dist/style.css": true
                }
            }
        }   
    }
}

Not sure, but the composer.json file might also need a tag with the name "symfony-ux":

{
    "keywords": [
        "symfony-ux"
    ]
}

[VincentLanglet]

I would go with the simplest solution to have a sonata prefix.

If renaming files give them the prefix, it may be the easiest solution

[onEXHovia]

For what have worked on my projects, you need to add this to the package.json:

{
    "name": "@sonata-project/admin-bundle",
    "symfony": {
        "controllers": {
            "filter": {
                "main": "dist/calendar.controller.js",
                "fetch": "lazy",
                "enabled": true,
                "autoimport": {
                    "@sonata-project/admin-bundle/dist/style.css": true
                }
            }
        }   
    }
}

Not sure, but the composer.json file might also need a tag with the name "symfony-ux":

{
    "keywords": [
        "symfony-ux"
    ]
}

I don't think it will work in our case. If you follow this guide https://symfony.com/doc/current/frontend/create_ux_bundle.html for each controller we must specify entrypoint
but webpack build one file app.js in output.

The approach you describe could make a package https://github.com/sonata-project/form-extensions and will would resuable ux package, but curently form-extensions trying to access our SonataAdmin app from window https://github.com/sonata-project/form-extensions/blob/2.x/assets/js/app.js#L16 and register controller.

SonataAdmin is the central app because create stimulus application