Mark Radford

+1

I'm interested in the differences as well, but I'm not sure there would be any benefit to using turboframes in this instance.

My understanding is that rather than replacing our form partial with a custom format.turbo_stream, we'd wrap the form in a turboframe and replace that with the standard format.html response.

However, in the video, Chris mentioned that if we used frames for the error handling, we won't be able to redirect easily out of the modal because we would be stuck inside the frame.

I believe may be solved by adding data-turbo-frame to our submit button:

Sometimes you want most links to operate within the frame context, but not others. This is also true of forms. You can add the data-turbo-frame attribute on non-frame elements to control this
https://turbo.hotwire.dev/handbook/frames#targeting-navigation-into-or-out-of-a-frame

I haven't tested this and wonder whether it would mess with the modal being opened or closed.

Can you please report back if you get a chance to play with the code for this episode to experiment with frames?

Was app/javascript/stylesheets/ used because app/javascript/src/ was not yet the default?

@chris any comment on using stylesheet_pack_tag with Hot Module Reloading (hmr)? The README states:

If you have hmr turned to true, then the stylesheetpacktag generates no output, as you will want to configure your styles to be inlined in your JavaScript for hot reloading. During production and testing, the stylesheetpacktag will create the appropriate HTML tags.

From Sigfrid's comment above, I'm guessing we should avoid stylesheet_pack_tag and instead import the css in packs/applications.js.

This article suggests a similar approach:

In order to do so [use hmr], we need to activate it in webpacker.yml
and not import the stylesheets via stylesheetpacktag since they will be included from packs/application.js

However, it seems to me that the suggested solution still uses stylesheet_pack_tag:

# packs/application.js
import './stylesheets'

and

# 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.

Sounds good to me. As someone who has still yet to use React in my Rails app, @Henrik, why do you recommend using webpacker-react over react-rails or react_on_rails ? Or why use any of these gems in the first place and just not use the Rails defaults?

@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:
http://pixelatedworks.com/articles/embracing-change-rails51-adopts-yarn-webpack-and-the-js-ecosystem/
https://thomasroest.com/2017/01/02/modern-javascript-and-ruby-on-rails-with-rails-webpacker.html

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?

Thanks again.

@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?

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?

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?