[META] css & js refactoring

[ju1ius]

Hi,

As stated in my last comment to #3647, I decided to split this big PR into several smaller ones to ease reviewing.

Since it's going to be a long story, this a meta issue to track the progress of these PRs.

Before the big todo-list, just a quick reminder on the main issues adressed:

• The association management templates are duplicated between all persistence bundles. Since sonata doesn't use a monorepo, changes commited to the doctrine-orm bundle are rarely ported to the others, who end up lagging behind. Moreover, a persistence related bundle shouldn't have to handle the UI for such generic stuff.
• The JS code for the form widgets is written directly inside templates, with a lot of twig interpolation, global namespace pollution, among other bad practices that make it hard to reason about, modify, extend, etc...
• No visual progress feedback nor error handling for AJAX requests.
• The public js api consists only of internal widget management functions that should never have been public in the first place. A public api should provide useful utilities for developers (like «retrieve the entity identifier of the list row I just clicked», «open my custom action in a modal dialog», etc...).
• there's more, but this is just a quick reminder...

  TODO

• [ ] Move CRUD association templates & form widgets to admin-bundle
  • [ ] admin-bunle PR
  • [ ] doctrine-orm-admin-bundle PR
  • [ ] doctrine-mongodb-admin-bundle PR
  • [ ] doctrine-phpcr-admin-bundle PR
  • [ ] doctrine-propel-admin-bundle depends on sonata-admin-bundle 2.x, so nothing possible ATM
• [ ] add frontend build pipeline allowing CSS & JS modularization
  • [ ] setup NPM + webpack + babel + PostCSS
  • [ ] split the main stylesheet into several smaller
  • [ ] remove legacy/dead CSS rules
  • [ ] propose a naming convention for css classes
• [ ] refactor javascript code
  • [ ] move ALL inline scripts to external ES2015 modules
  • [ ] add error handling and progress visual feedback to AJAX requests.
  • [ ] make association buttons potentially available to any form widget
  • [ ] replace the old Admin js API with something actually useful for developers
• [ ] additional features
  • [ ] display list view's show & delete actions in a modal.
  • [ ] replace the unmaintained iCheck javascript library by a small, pure-CSS implementation.
  • [ ] Shift+Click batch selection support for the list views

[soullivaneuh]

setup NPM + webpack + babel + PostCSS

Is this about css/js vendor removing from reposiroty? Please also consider this: https://github.com/sonata-project/dev-kit/issues/137

Also in this case, a bower package must be provided too. Even if you don't like it, both are used so both should be provided.

doctrine-propel-admin-bundle depends on sonata-admin-bundle 2.x, so nothing possible ATM

This package is pending. Maybe it will be deprecated.

move ALL inline scripts to external ES2015 modules

ES2015?

replace the unmaintained iCheck javascript library by a small, pure-CSS implementation.

Interesting. Could you please ellaborate your plan?

[ju1ius]

ES2015?

:sparkles: ECMAScript 2015 edition. AKA ES6, AKA ECMAScript-Next, AKA Javascript as it should be written today.

Interesting. Could you please ellaborate your plan?

Now that all browsers support CSS3 selectors, javascript is not needed anymore for such a simple feature. See here for a simplified example, and here for the actual implementation.

Is this about css/js vendor removing from reposiroty?

No, not yet. Again, it's about the internal admin-bundle's assets.

• splitting the stylesheet into small, focused modules. See https://github.com/ju1ius/SonataAdminBundle/tree/js-refactoring/Resources/assets/css
• Moving the inline javascripts to external ES2015 modules. See https://github.com/ju1ius/SonataAdminBundle/tree/js-refactoring/Resources/assets/js

All of this was in #3647.

[soullivaneuh]

:sparkles: ECMAScript 2015 edition. AKA ES6, AKA ECMAScript-Next, AKA Javascript as it should be written today.

So ES2015 is a kind of pre-language. Looks interesting, but this not the only one. This should be discusses on dev-kit before and I would like @rande opinion for this before.

Now that all browsers support CSS3 selectors, javascript is not needed anymore for such a simple feature.

Looks nice indeed! :+1:

Would be great look at a library for that instead of reinventing the wheel.

No, not yet. Again, it's about the internal admin-bundle's assets.

What is the goal of npm in this case?

[ju1ius]

So ES2015 is a kind of pre-language.

OMG NO!!! This is not the same as say CoffeeScript, TypeScript, Elm or ClojureScript, which are separate languages that compile to javascript. ES2015 is the current stable version of the javascript language. From the wikipedia page:

ECMAScript (or ES) is a trademarked scripting-language specification standardized by Ecma International in ECMA-262 and ISO/IEC 16262. It was based on JavaScript, which now tracks ECMAScript. It is commonly used for client-side scripting on the World Wide Web. Other implementations of ECMAScript include JScript and ActionScript.

The ECMA group (AKA TC39) is the standard commitee responsible for the ECMAScript (=== javascript) language specification. Since 2015 they decided to publish one revision of the standard per year.

The 2015 version is already fully suppported in Chrome 51, Firefox 47, and Node 6. Support in Edge 13 is currently at 80%. And most importantly, you can use it today in all browsers thanks to Babel. See the compatibility table.

[ju1ius]

What is the goal of npm in this case?

• Dev dependencies (e.g. linters, testing tools, build tools...)
• external dependencies that are used only inside one bundle.
• npm is also a task runner (the "scripts" entry of a package.json)

See https://github.com/ju1ius/SonataAdminBundle/blob/master/package.json

[soullivaneuh]

OMG NO!!!

Wow, stop your heart attack!

I have bench of notifications to read, so I try to read quickly. Sorry if I'm wrong.

So if I understand well, ES2015 is the new Javascript syntax to use, not compatible with all browser and babel is a kind of converter to the old syntax in order to keep compatibility.

Am I finally right? :-)

[ju1ius]

Wow, stop your heart attack!

:sweat_smile:

ES2015 is the new Javascript syntax to use

Yep. It is the latest stable version of the standard. Currently there's is also ES2016 (the next stable version) and ES2017 (the next-next stable version).

babel is a kind of converter to the old syntax in order to keep compatibility.

It is more than that, but yes, in a nutshell it's main use-case is to

• transpile the latest syntactic features into a syntax compatible with all environments.
• polyfill the new features and built-in objects (Generator, Promise, Symbol, WeakMap, Set..) or new methods of existing buit-ins (Array.prototype.includes, Object.entries...) in non-supporting environments.

From the Babel Handbook introduction chapter:

Babel is a generic multi-purpose compiler for JavaScript. Using Babel you can use (and create) the next generation of JavaScript, as well as the next generation of JavaScript tooling.

JavaScript as a language is constantly evolving, with new specs and proposals coming out with new features all the time. Using Babel will allow you to use many of these features years before they are available everywhere.

Babel does this by compiling down JavaScript code written with the latest standards into a version that will work everywhere today. This process is known as source-to-source compiling, also known as transpiling.

[grekpg]

Any news about integration with webpack ?

[Wharenn]

Hi @sonata-project/contributors,

Since this issue was opened, webpack-encore has been released and might give us a good start to deal with the (mess of) dependencies and initiating the move to an ES6 syntax on Sonata Javascript.

Is there any plan so far to improve the assets building and bundling?

[core23]

For the monent, no. But maybe you can give it a try @Wharenn

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.