8000 [WebProfilerBundle][TwigBundle] Compile assets by ro0NL · Pull Request #29537 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[WebProfilerBundle][TwigBundle] Compile assets #29537

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 14 commits into from
Closed

[WebProfilerBundle][TwigBundle] Compile assets #29537

wants to merge 14 commits into from

Conversation

ro0NL
Copy link
Contributor
@ro0NL ro0NL commented Dec 9, 2018
Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets maybe #29194
License MIT
Doc PR symfony/symfony-docs#...

This is a quick POC how we can extract pure CSS/JS and compile a distribution, to be committed and used by the components.

The idea is to introduce somewhat of codestyle and modern stuff. I followed the webpack-encore-bundle setup in a new local assets/ folder (without the composer constraint). cc @weaverryan this was fun 👍

The goal is to provide a single source of truth and ease maintenance. And eventually allows us to move forward in a more modern way.

I've discussed some ideas with @javiereguiluz, but for now im aiming preserve BC fully and focus on the inventory first, sort of speak.

The missing step here is still a simple binary to copy the build files into the components under src/, e.g.

# compile profiler, toolbar, exception-page, welcome-page
$ assets/compile

Copy link
Member
@stof stof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we go that way, the assets folder should be ignored in the archive (through .gitattributes) as it should be purely a contributor thing (the bundles should use the final version).

@ro0NL
Copy link
Contributor Author
ro0NL commented Dec 9, 2018

@stof in less then 2 hour (including initial research / setup) ive replicated the tabs component successfully (it actually works):

image

(i havent include the util classes yet, such as .hidden).

I think this is very viable, IMHO. Developing in PHPstorm is a joy, and i tend to take the extra compile step for granted. JS community would embrace this most like likely i guess.

I was hoping @javiereguiluz can help in transferring the components etc., so we can do a clean-up/improvement round right away. Each component should define it's own vars at least, and perhaps we can reduce the no. of global/duplicate stuff scattered around.

Ultimately that would ease the migration to maybe React/Vue components 😱 (but put on a diet; let's see :P)

@ro0NL
Copy link
Contributor Author
ro0NL commented Dec 9, 2018

The new approach is ready to EOL the old one (i think we should). In theory we can now move everything per-case (ie. this PR can be merged as-is) and is 100% BC (ive only updated tabs in the profiler for now).

@javiereguiluz
Copy link
Member

Roland, thanks for working on this change. To give more context: as you said, during the SymfonyCon we talked about this. The current situation is not ideal (we have duplicated CSS/JS assets, the JS code is defined inside Twig code, etc.)

This is slowing us down. It's not easy to do improvements in the toolbar or profile, and we're thinking about some cool changes to make them more useful (think about things like the dynamic filter added by Roland in 4.2).

But don't worry about this change. We're not going to do useless changes and we're not going to complicate things for the community. We're very focused on improving things to provide more value to end users. Thanks!

@ro0NL
Copy link
Contributor Author
ro0NL commented Dec 10, 2018

But don't worry about this change. We're not going to do useless changes and we're not going to complicate things for the community.

Agree. Im striving for the opposite here long-term. That said, i do like to introduce some technical/conceptual changes with this PR, in an effort to avoid never ending iterations.

  • we should scope by default, instead of relying globals to be defined by SF.
--sf-some: x; 
.sf-hidden {} 
.sf-component .local {}
  • we should theme by default:
// component.css requires globals.css

--sf-component-some: --var(--sf-global);

.sf-theme-dark {
   --sf-component-some: --var(--sf-dark);
}

.sf-component {
  .local {
  }
}
  • keep the global definition small (only color/size vars + .sf-hidden like utils)
  • unify duplicate concepts (i think we have n types of toggle implementations, table styles etc)

@nicolas-grekas
Copy link
Member

Shall we close here?

@ro0NL
Copy link
Contributor Author
ro0NL commented Jan 27, 2019

i guess :}

@ro0NL ro0NL closed this Jan 27, 2019
@ro0NL ro0NL deleted the assets branch January 27, 2019 15:41
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.3 Apr 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0