Compatability with Webpacker (looking forward to Rails 6.0)

[klaustopher]

Hi there,

I am currently moving over my rails app from the Asset pipeline to webpacker. The only thing that is blocking me currently is that filterrifc is requiring me to add assets to the asset pipeline. DHH has already announced that webpacker will be the default asset pipeline for Rails 6.0. So I think this great gem should also move forward towards the future ;)

I would be willing to do the work and extract all the assets into a NPM package and work on the logic to chek how to load the files, etc. But before I start with this I wanted to ask what the direction is that you want to take this ;) Maybe in the meantime we can also get rid of the dependency on jquery and move to the fetch api and make this a bit more future proof. Happy for particpation in the discussion.

[descovi]

Hi :) for my team, jquery dependency is not a big problem (we still use sometime). Instead webpacker compatibility can be a very good improvement.

[jhund]

@klaustopher thanks for reaching out re future of Filterrific. I see two main ways of using Filterrific:

1. Classic Rails with server rendered views (and likely presence of jQuery, Turbolinks, webpacker for assets). I'd be interested in hearing your thoughts on how to best accommodate this scenario.
2. Rails as an API server (mostly via JSON). In that case no assets are required for Filterrific. We just published a new demo for this use case: https://github.com/jhund/filterrific_json_api_demo

[preetsethi]

1. Classic Rails with server rendered views (and likely presence of jQuery, Turbolinks, webpacker for assets). I'd be interested in hearing your thoughts on how to best accommodate this scenario.

@jhund @klaustopher What do you think about this?

1. Modify ActionViewExtension to use form_with and rails-ujs

2. Use webpacker defaults for Rails 6:

   Active Storage, Action Cable, Turbolinks, and Rails-UJS is loaded by a new application.js pack in app/javascript by default (unless any of the frameworks have been opted out).

// app/javascript/application.js
require("@rails/ujs").start()
require("turbolinks").start()
require("@rails/activestorage").start()
require("channels")

3. Add in a sprinkle of stimulus.js

   rake webpacker:install:stimulus

// app/javascripts/packs/application.js
import { Application } from "stimulus"
import { definitionsFromContext } from "stimulus/webpack-helpers"
const application = Application.start()
const context = require.context("controllers", true, /.js$/)
application.load(definitionsFromContext(context))

4. Use stimulus-rails-ujs (pardon the haml, just showing the example code)

   %ul#response
   %li An existing content piece

= form_with model: @model, data: { controller: 'rails-ujs', action: 'ajax:success->rails-ujs#success', placement: 'append', response_target: '#response' } do |f|
  = f.text_field :field_name
  = f.submit

5. Finally, refactor logic from filterrific-jquery.js into an equivalent stimulus controller.

It would be troublesome to generalize + gemify webpacker compatible assets (for example, detecting whether the user application already has rails-ujs / stimulus configured, merging files). I'm sure I could figure it out, would likely do something like railties does on initial configuration with templating.

However, I think a much better approach might be to start off using the API only config for filterrific and separate the necessary JS assets into an npm package. This way, initial webpacker setup is on the user and they must ensure rails-ujs + stimulus, but they have complete control of their webpacker configuration and we don't have to muck around with any config file templating.

Pros

• Drop jQuery dependency
• Largely use Rails 6.0 defaults re: webpacker / rails-ujs
• Stimulus is cool (stimulus fanboy here haha)

Cons

• My proposal is clearly only targeting Rails 6+ (I think webpacker supports Rails 5.1+ perhaps?)
• Forces stimulus on users. (but to defend stimulus, its pretty lightweight)

@jhund @klaustopher Thoughts? Questions? Comments?

Specifically @jhund These are pretty big changes that I am proposing, how would you want to handle this in terms of logistics? A rails6 branch? A divergent fork named filterrific-webpacker or something?

Please get back to me guys, I'd love to start working on this. I'm working on a new project that's in dire need of what filterrific offers, but its Rails 6 + webpacker + stimulus and I have no desire to add sprockets and a jQuery dependancy.

[alydersen]

Any progress on this? I have a project that is heavily dependant on Filterrific (love it, BTW) but is moving over to webpacker/Stimulus

[awh-tokyo]

I'm working on a new project that doesn't use the old asset pipeline at all. Filterrific is my usual go-to for this sort of thing, but is the front-end javascript really not available as an NPM package?