Conversation
7967631 to
d6262d7
Compare
actionview/lib/action_view/engine.rb
Outdated
There was a problem hiding this comment.
How about leaving this in lib/action_view/railtie.rb? The fact that its superclass is now Rails::Engine doesn't mean it needs to move.
d6262d7 to
5a7bed1
Compare
There was a problem hiding this comment.
Perhaps we should always use rails-ujs and eliminate *_ujs
There was a problem hiding this comment.
agree, I was thinking exactly the same
5a7bed1 to
7184289
Compare
There was a problem hiding this comment.
I think this line needs another space to indent it fully 😁
|
Congrats @liudangyi, nice work! ❤️ |
|
This needs changelog as well 😃 |
7184289 to
84f8cb5
Compare
|
CHANGELOG entries added 😊 |
|
Does the compiled |
|
@javan the different options were discussed in #25208 (comment), B) was discarded but maybe A) is preferred more than the current approach /cc @dhh @rafaelfranca In my opinion is a better idea to keep the source code out of Rails repo because of maintenance (typically the maintainers of js integration libraries are different than the maintainers of Rails and that's why we have a "Javascript" collaborators group on Github) and distribution (we don't expect to sync releases of this library with the releases of Action View like we do for Action Cable) Personally I'll prefer to keep the current approach or B) making it a gem. |
|
I think it should be a gem that is explicitly named in the Gemfile. For the relevant helpers to work, actionview needs a UJS implementation to be present -- but that could be this new one as supplied by us, it could be jquery-rails, or it could be managed by another asset manager. We have plenty of precedent for features that only work, or work much better, if an additional optional gem is present -- from database adapters, to bcrypt passwords. And the "U" in "UJS" is supposed to promise that the helpers' HTML output will still get the job done even with no JS available. (After all, even if we ship it, we can't guarantee it's included on a given page.) Mostly, I'm worried that having two UJS assets floating around inside an application risks confusing conflicts, so it seems better that this new one will Properly Go Away if it's not being used. (Particularly given that while we're not yet strongly committed to the idea, and a good way away from requiring it, it seems likely we're going to end up with a 3rd party asset manager as the default happy path in the not-too-distant future.) I agree with @javan that it should at least be part of the build process, not a manually copied file, if we do choose to ship it built-in. And if we're bundling the compiled result into the AV gem, then we do seem to intend to sync releases of the library -- in the most physical way possible. 😕 |
|
We currently have two "systems" for incorporating JavaScript:
I'd rather not introduce a third, especially if it's copy+paste |
|
Thinking about the release process I still prefer it to be a gem and for
|
|
I would suggest to make it a separate gem. An additional line in |
|
I'm curious as to why we think this package is going to need a higher But, again, if Rafael is doing the release work, and he prefers a separate On Mon, Nov 21, 2016 at 10:07 AM, Dangyi Liu notifications@github.com
|
dd2e5d8 to
edec43d
Compare
|
Updated and now jquery-ujs gem is added to Gemfile. |
3750e8d to
277b5f9
Compare
rafaelfranca
left a comment
There was a problem hiding this comment.
If we claim to this library to be ubstrusive why even bother to allow people to chose another one? I'm more inclined to just remove support to other javascript drivers in the generators
|
|
||
| gems << GemfileEntry.version("#{options[:javascript]}-rails", nil, | ||
| "Use #{options[:javascript]} as the JavaScript library") | ||
| if options[:javascript] |
There was a problem hiding this comment.
Why doing this here and not using the already existing default option in Thor?
| <% if options[:javascript] -%> | ||
| //= require <%= options[:javascript] %> | ||
| //= require <%= options[:javascript] %>_ujs | ||
| <% end -%> |
There was a problem hiding this comment.
Would not this add both in case people have Jquery-ujs?
There was a problem hiding this comment.
For users passing the -j jquery option this file will be like:
//= require jquery
//= require rails-ujs
So we are making rails-ujs the default even for jQuery users and not allowing people to chose another driver
|
@rafaelfranca yup, we are doing exactly that in generators, even the jQuery users will get |
|
👍 |
|
@rafaelfranca I think that's a strong argument for just including it in Action View. We don't need an adapter for this. This is UJS support to make the Rails helpers work and they just rely on standard JS. No reason to have a jQuery or whatever version of them imo. |
|
@dhh agree on that @rafaelfranca wdyt? |
|
This will make the release process really hard because we will have to clone two repositories build the dist file etc. We can make it simpler though if we move all code to inside action view. That way we can release it in the same way we do release actioncable. But doing this we will lose the separated issue tracker and will complicate our test matrix that is already slow, and complicated. If we are going to move the entire code to action view I'm positive about it, but there are those drawbacks that I pointed. |
Rails dropped jQuery as a dependency back in rails/rails#27113. That commit removed 'jquery-ujs' from the application.js and replaced it with 'rails-ujs'. Since we aren't using 'jquery-ujs', we don't need the 'jquery-rails' gem. As for the test JS, `$.fx.off = true` shouldn't be necessary if we aren't using jQuery, and `$.ajaxSetup({ async: false });` seems to have been for Akephalos, which we no longer use.
Rails dropped jQuery as a dependency back in rails/rails#27113. That commit removed 'jquery-ujs' from the application.js and replaced it with 'rails-ujs'. Since we aren't using 'jquery-ujs', we don't need the 'jquery-rails' gem. As for the test JS, `$.fx.off = true` shouldn't be necessary if we aren't using jQuery, and `$.ajaxSetup({ async: false });` seems to have been for Akephalos, which we no longer use.
Rails dropped jQuery as a dependency back in rails/rails#27113. That commit removed 'jquery-ujs' from the application.js and replaced it with 'rails-ujs'. Since we aren't using 'jquery-ujs', we don't need the 'jquery-rails' gem. As for the test JS, `$.fx.off = true` shouldn't be necessary if we aren't using jQuery, and `$.ajaxSetup({ async: false });` seems to have been for Akephalos, which we no longer use.
As discussed in #25208 we have decided to remove jQuery from default stack and use a vanilla version of the ujs driver named rails-ujs instead.
This Pull Request remove
jquery-railsfrom new applications and providesrails-ujsthroughAction View(to do this I had to convertActionView::Railtieinto anEngine).The new rails-ujs was developed by @liudangyi as part of Google Summer of Code, all credits for this goes to him and to his mentor @pixeltrix 👏 👏 👏 👏 👏