We've been busy with the Symfony UX Initiative. Today I'm excited to share the next round of updates.
Encore 1.0 Released (Webpack 5 Support)
Contributed by
Vincent Le Biannic
in #645.
After 4 years (of already being stable), we're proud to welcome Webpack Encore 1.0 to the family. What's new? Excellent question!
- Encore now uses Webpack 5, which itself introduces a lot of features.
- Persistent build cache: thanks to a new
Encore.enableBuildCache()
method, you can enjoy faster "subsequent" builds. See Encore's index.js file for more details.
To upgrade, run:
1
$ yarn upgrade "@symfony/webpack-encore@^1.0.0"
When you next execute Encore, it will probably notify you of other dependencies that you should upgrade. See the full 1.0.0 CHANGELOG.
symfony/stimulus-bridge 2.0
At the heart of the Symfony UX Initiative is Stimulus and the stimulus-bridge, which helps you automatically load controllers from the UX Packages as well as your own custom controllers. 2.0 brings a few awesome updates.
If you want to go deeper, we'll talk about Stimulus in detail in a Stimulus Tutorial on SymfonyCasts soon.
Lazy Controllers
Contributed by
Ryan Weaver
in #15.
First, in controllers.json
, the webpackMode
key has been replaced by fetch
.
This enables a powerful new feature: if you set fetch
to lazy
for a
package, that package's JavaScript won't be downloaded until it's needed!
How is that possible? Internally (by leveraging Stimulus & Webpack), the controller
code is split into its own JavaScript file. Then, the moment a matching
data-controller=
appears on the page, the file will be downloaded and executed.
A great use-case is ux-chartjs. By setting fetch: 'lazy'
, you can build
a Chart in PHP and render it on any page... but without incurring any extra code
in the JavaScript that's downloaded on page load.
Laziness for Your Controllers
This "lazy controllers" feature is so neat that we wanted to allow you to use it
for your own controllers. By default, if you put a controller file in
assets/controllers
, it will be automatically loaded but included on every
page. What if you only need that controller in rare situations?
You can now tell the stimulus-loader
to load your controller "lazy" by decorating
it with a special comment:
1 2 3 4 5 6 7
// assets/controllers/hello_controller.js
import { Controller } from 'stimulus';
/* stimulusFetch: 'lazy' */
export default class extends Controller {
// ...
}
By including the /* stimulusFetch: 'lazy' */
comment, this entire controller
file (and its dependencies) won't be downloaded until a matching data-controller
element appears on the page.
Upgrading to stimulus-bridge 2.0
To upgrade, make sure you have 2.0 of the package and at least 1.0 of Encore:
1 2
$ yarn upgrade "@symfony/stimulus-bridge@^2.0.0"
$ yarn upgrade "@symfony/webpack-encore@^1.0.0"
Also make sure you have the latest symfony/flex
so it sets the new fetch
option in controllers.json
:
1
$ composer up symfony/flex
Finally, in assets/bootstrap.js
, make the following changes:
1 2 3 4 5 6 7 8 9
import { startStimulusApp } from '@symfony/stimulus-bridge';
- import '@symfony/autoimport';
- export const app = startStimulusApp(require.context('./controllers', true, /\.(j|t)sx?$/));
+ export const app = startStimulusApp(require.context(
+ '@symfony/stimulus-bridge/lazy-controller-loader!./controllers',
+ true,
+ /\.(j|t)sx?$/
+ ));
Note
Version 2 also changed the format of the third party controller names. For example,
the ux-chartjs controller was previously @symfony/ux-chartjs/chart
and
is now called symfony--ux-chartjs--chart
. If you're using any UX library
version 1.2 or higher (e.g. symfony/ux-chart-js), make sure to upgrade to
the latest version of stimulus-bridge.
That's it! Keep watching the blog and Symfony UX for more updates!
Great job Ryan !!
That is absolutely amazing, thank you A LOT!
Thank you ! Keep up the good work !
That sounds really, really amazing.
But I wonder how best to do that within my own bundle development. First - how is there the dev workflow? I mean encore will not automatically recognize my controllers in my bundles, will it?
I'm assuming that that's not the case. Then, after the question of the workflow for development, the question arises: "How do I get my stimulus controller into the application that installs the bundle."
I think I've read almost everything about this UX stimulus thing by now. But I think that the bundle development in Symfony is not that important. And I also think that's bad for Symfony and the community.
In contrast, it is wonderfully easy to create Laravel Packages. Everything is geared towards creating digital, shareable, reuseable products. With Symfony, I have to keep wondering how I can get my assets to customers now. That's sad.
And I don't see that this issue will get better soon. Or am I wrong about this?
@Michael yeah seems that in Laravel it's easier to create packages and you can find more docs about everything and tutorials. That laravel daily is kinda nice around here even the news are hard to read and mostly are about what symfony fixed or added new features. After years of symfony few months ago i've started thinking on moving on laravel because of the multitude of things you can find there. :(