How do we use jQuery and bootstrap and their alternatives in Yii 3?

Guys, someone has to develop frontend bindings for altenative JS framework, if you don’t want to use jquery.
Since it’s pretty complex task, nobody has done it yet - you might be the first one … :slight_smile:

@Knight_Yoshi what do you mean by “support”?

@lubosdz Yii isn’t going to be tied to jQuery. Debug extension is close, the rest will follow. Not sure what do you mean by “bindings”.

I mean having source JS files that use require and module.exports (or ES6 native import and export with Webpack and/or Babel) so that it can be bundled in our own JavaScript, along JS files that are already browser-ready.

I have no idea how that works :slight_smile: The answer is… probably.

i have same problem, already mentioned here

It’s similar to separating responsibilities of PHP into different files and then using the file. Then you can import them into another file as a dependency. Using a bundler like Webpack or Rollup can create a single file and/or smaller bundles, such as vendor files vs core application files.

Another advantage is that Webpack can tree shake to remove unused JS (I believe with the import/export statements only). So if we have a form we can import the Yii JS validator and just the validation rules needed for that form instead of loading all of the Yii JS, when much of it probably isn’t necessary for that page.

So a quick example would be (just to get the idea across, not meant to be 100% accurate)

import Validator from '/vendor/yiisoft/yii3/src/js/validation/Validator'; 
import LengthValidator from '/vendor/yiisoft/yii3/src/js/validation/LengthValidator';

var maxlength = new LengthValidator({max: 8});
var inputField = document.getElementById('someinput');
var validator = new Validator(inputField, maxlength);
// ...

Of course that’s a rough example thrown together, but it should convey the idea. And that would all be bundled and have a dist version ready to go without the developer(s) having to use Node, bundlers, or the like. However, those that do would be able to include in their own JS.

1 Like

Doesn’t that require polyfills for a good range of browsers support?

Well in the example above it would run through a bundler, I recommend Webpack. No polyfill needed. Webpack would bundle the files as configured by the developers (can code split to have multiple smaller bundles, vendor bundle, or one big bundle).

So it outputs it as a normal JS file with Webpack wrappers that don’t have the imports/require, or export statements, it’s converted to normal function calls.

I created this simple example:

So the source is comprised of three files, the entry file (index.js), a class Person, and what would be a config file with names (members of the Yii team ;D ).

The names.js and Person.js are imported into the the index.js and bundled as one file, built in /dist, with the magic of Webpack and some Babel (added a touch of ESLint stuff for preventing false positives with validation). Babel isn’t even necessary (but I’d recommend). Babel can handle transpiling code, especially experimental features into standard syntax, as well as provide necessary polyfills. The output in the dist file is browser-ready.

1 Like

For instance Babel polyfills provided by or

Or handling class properties (currently a proposal)

So Node + Webpack + Babel provide a great way to handle this.

Isn’t Webpack out of trends already?

Definitely not!

5.7M weekly downloads

I don’t want to deal with webpack since I am already using Gulp. Yes, and even Bower! I simply do not have the time nor the patience to stay in the JS loop.
I hope it doesn’t become a requirement. :wink:

If you read, I said they would also ship an already bundled version, just like how they do now. Webpack would be for people, like myself, that want to have finer control over the JavaScript build.

I am already handling all assets myself, JS build and CSS, etc. So, instead of assuming Webpack, I would like being able to either carry on with whatever I’m doing or - even better! plug in whatever I am using (Gulp and friends) as an alternative to webpack (which I, sorry to say, am not very fond of).

I’ve used Gulp. It’s just a task runner, not a bundler like Webpack. In fact, there’s a Node module that allows you to use Webpack in a Gulp task. Fundamentally they serve two different purposes, and Gulp doesn’t have the functionality that Webpack. You can mix and match different things to achieve something similar, but they’re two different tools for different purposes.

Also for anyone that’s curious, this is the module I’m talking about that allows you to use Webpack in Gulp

I know what it is. And I totally do not need it at all :smile:
It’s got terrible documentation and there is a lot of overlap between Gulp and it.
I do acknowledge that you might need a bundler. Mainly when you are developing complex Node/JS applications. Definitely not when you are developing a PHP application with a couple of scripts. :stuck_out_tongue:

But Yii doesn’t have exclusively PHP. It has JavaScript as well. It should provide more functionality to be able to allow the developers to have control over how the JavaScript is deployed to the browser; i.e. in my own JS files with only the components necessary for minimum file size.

The developer is more capable of determining what is needed for the project/page and can optimize for that necessity. Your personal preference shouldn’t exclude the overall benefit that Webpack and the like can provide for people that want to use it. You’re saying, “I don’t like it, that’s why it shouldn’t be included.” That’s not a very good argument.

It is a very good argument, actually :wink:
What I mean is: I would like this to be wholly voluntary and not a requirement.
I am already exercising full control of my assets, without the help of Yii.

That said, I am glad to see that there is work being done to decouple Yii from jQuery and Bootstrap. I am currently using Bootstrap4, which means I had to remove Gii and Debug from my project (because they depend on Bootstrap)

It’s not, because Yii isn’t specific to your project. It’s for everyone that wants to use it, so it should accommodate for different needs.
Your argument is valid for your projects, not collectively for people who have different needs.

Again, I said it should be optional. They can include a bundled version of their JS. In fact, doing it this way they can work with the same source as others and it would make it easier to maintain for the contributors/collaborators, then just bundle it and ship it. No Webpack necessary for people who don’t want it.