@chris any comment on using
stylesheet_pack_tag with Hot Module Reloading (hmr)? The README states:
From Sigfrid's comment above, I'm guessing we should avoid
stylesheet_pack_tag and instead
import the css in
This article suggests a similar approach:
In order to do so [use hmr], we need to activate it in
and not import the stylesheets via
stylesheetpacktagsince they will be included from
However, it seems to me that the suggested solution still uses
# packs/application.js import './stylesheets'
# app/views/layouts/application.html.erb <%= stylesheet_pack_tag 'stylesheets', 'data-turbolinks-track': 'reload' unless Webpacker.dev_server.hot_module_replacing? %>
@Chris I found your Stimulus github issue but I also don't undertsand why
ajax:beforeSend is required to get
preventDefault to work:
"this is a remote form using rails ujs, and we have to use the AJAX before send event, and we'll pass that into our tweet form submit action."
In my case I'm simply trying to use
preventDefault with a
remote link but I can't get it to work as expected.
Posted in ReactJS with Rails
Sounds good to me. As someone who has still yet to use React in my Rails app, @Henrik, why do you recommend using
react_on_rails ? Or why use any of these gems in the first place and just not use the Rails defaults?
Posted in Using React
@Melanie, I think you also have the option of using React with Rails without using either of those gems (react_on_rails and react_rails).
I believe Rails 5.1 will include webpacker that will allow for React to be added to your Rails app with:
rails webpacker:install:react # Install everything needed for react
I've yet to try this myself but am just letting you know that it might be an option.
Some articles that touch on this:
Is there anything you don't know?
Do you have any thoughts about using an approach like https://github.com/meagar/r... to enable basic caching of assets?
I'm basically trying to adopt the "offline first" approach for my mobile app and have decided that it's currently not possible with Turbolinks 5. If you're interested, I had a brief discussion with Chris about it in the comments here
Thanks for taking the time to reply. It's worth noting also that ServiceWorkers currently aren't supported on iOS or Android webviews: https://developer.mozilla.o...
So my current conclusion (based on my current knowledge level) is if you want to adopt the "offline first" mentality with your native/hybrid mobile app then avoid Turbolinks 5 and instead look at other solutions (ie fully native in Swift, React Native with Realm, etc).
@excid3:disqus As far as I can tell the caching used by turbolinks is not available offline. Do you agree with this?
Thanks for taking the time to reply. Your tips are a massive help.
I'm slowly getting my head around the basic setup and code in xcode.
Do you have any experience in adding offline support to your Turbolinks hybrid app? If yes, are you able to give some basic information on your implementation?
@patrick did you end up finding any good resources?
@aaron, any update a year and a half later on what technology you chose to use and any lessons learned?
Posted in Turbolinks 5 Forms for Mobile Discussion
Any idea on when we might see some of these episodes? Or have the already happened and I missed them?
This was my issue and soon as I fixed it
Are you able to elaborate on how you fixed it so myself and others can benefit from your solution?
Posted in ReactJS with Rails
I've never used React before so this comment may be irrelevant, but would it make sense to wait for Rails 5.1 to make a React series when Yarn and Webpack are available in Rails?
I think Jacob has given some great advice, especially with regards to using
Nothing aginst Heroku, but due to the way they bill, I would be concerned of having spike charges due to things like this.
I don't think you get charged extra from Heroku for having spikes and exceeding your memory quota. I think when you exceed your memory quota you start to use swap memory, which is less than desirable, but I don't think you are charged extra. https://devcenter.heroku.com/articles/ruby-memory-use
Posted in Stripe gems: Koudoku or Payola
Thanks all for taking the time to give feedback. Looks like vanilla Stripe API is the way to go.
I've tried a couple of these gems and often found I was boxed into the way they do things which I could break out of, but at that point I'd basically not be using their gem that much.
I applied similar logic to avoiding Devise. In hindsight this may have been a mistake as Devise seems extemely poplular.