Episodes
murat.ustuntas PRO said 4 months ago on Hotwire Dashboards :
It was one of the things I've been waiting for for a long time. Thank you for your work.

dev said 4 months ago on Hotwire Dashboards :
Thank you. Helpful stuff!

The source code for displaying random images is lost somewhere)


David Kimura PRO said 4 months ago on Hotwire Dashboards :
  the random images was just a turbo frame tag which pointed to another controller which used the Faker gem to get

Faker::LoremFlickr.image

I ended up cutting it from the episode since it was very repetitive, following the same concepts as the small weather panels, and the episode was already running really long.

gabi PRO said 4 months ago on Hotwire Dashboards :
Thank you so much for this episode! I work maintaining and developing an application that has a dashboard very similar to this example and I can see how Hotwire could improve things for us tremendously. 

storrence88 PRO said 4 months ago on Hotwire Dashboards :
Great episode! Thanks so much for explaining concepts so well!

choffman PRO said 4 months ago on Hotwire Dashboards :
Great episode!

AhmedNadar PRO said 4 months ago on Hotwire Dashboards :
What a fantastic episode David. 

Regarding Rails 7, have you worked with import_maps instead of jsbundling and cssbundling? 

David Kimura PRO said 4 months ago on Hotwire Dashboards :
  I've dabbled around with import_maps and it is getting better. However, I still prefer jsbundling (esbuild). I don't mind having node as a dependency if it means that the overall dev experience is better/easier.

AhmedNadar PRO said 4 months ago on Hotwire Dashboards :
  I'm working on a new project, a marketplace, and trying both ways (esbundling and import_maps) to create simple functions/features and using external libraries. And to be honest, while node_modules got much slimmer still caused some issues, beside performance and development's joy is better with import_maps.

If it is possible, have an episode highlights import_maps usage and compare it to an esbuild episode.

itsterry PRO said 4 months ago on Hotwire Dashboards :
Dave, that was fabulous. Thank you

James Ell PRO said 4 months ago on Hotwire Dashboards :
Question on the dashboards: Instead of querying the data directly from the Weather API on every refresh, what we queried it every five minutes via a job and wrote it to a DB.

Could we use Turbo to automatically refresh the temperature field on the dashboard and provide current data as the DB is updated via broadcasts_to/after_create_commit?

This should make the API portion 'automatically update' without any forced refreshes or JavaScript, correct?

David Kimura PRO said 4 months ago on Hotwire Dashboards :
  That's correct. You'd just have to have a relevant turbo stream that is subscribed to the same channel that the broadcasts is going to.

jcquarto said 4 months ago on Hotwire Dashboards :
is this necessarily Rails 7 ? I'm trying to get it to work on 6.1.4 with the hotwire-rails gem

jcquarto said 4 months ago on Hotwire Dashboards :
Also, would this act any differently if you had content in a modal which was the turbo-frame?  For example, I have one modal for the page, and N number of elements on the page and when I click on one of those elements it opens the modal and updates its content based on the specific element?

In your example app, for instance, what if clicking on a comment brought up a modal with, say, the comment's author ? (just as a concept)

David Kimura PRO said 4 months ago on Hotwire Dashboards :
  jcquarto It should work with Rails 6.x. However, you likely had turbolinks in that application and you would have to convert it over to Turbo (hotwire) to work properly.

As far as the modal stuff goes. This can get a bit trickier. Likely, I would have an empty turbo frame tag in the layouts for the modal. When you click the Edit Comment button, it would make a request back to the rails application for that comments#edit. From there you would have a turbo_stream response and an associated edit.turbo_stream.erb file which would then replace the empty turbo frame tag in the layouts with a partial which had that turbo frame tag and the modal information. You would then have, within that partial, a stimulus controller something to launch the modal when the controller connects. Hope this makes sense.

jcquarto said 4 months ago on Hotwire Dashboards :
my eyes started to glaze over on that second paragraph! :). seems much more complex, even though the modal is no more than a hidden div.  The need for a specialized stimulus controller, yes, though I was hoping for just throwing an event up (to @ window or @ document) that would be listened for by the frame inside the modal

David Kimura PRO said 4 months ago on Hotwire Dashboards :
You could render the modals inline with the content, but the main issue there is that you're spending CPU cycles and bandwidth in creating these modals that might never be triggered. This does sound episode worthy as it can be a complicated feature. 

jcquarto said 4 months ago on Hotwire Dashboards :
you've correctly described what worried me. I probably would have hundred of cards from which I want to click to see the modal for more details, but only ever click on a few. So yes, it doesn't make sense to have a 1:1 of card to modal. I'd rather just have one modal, and re-write its content as a card is clicked (based on data from the card, likely just an id for Rails to call -- roughly 'card_modal_path(17)', that sort of thing)

jcquarto said 4 months ago on Hotwire Dashboards :
I'm was able to get some code to work that does "many elements calling one modal". No need for a stream. Hung up on using a modal from tailwindui, though

johnpitchko said 3 months ago on Hotwire Dashboards :
How would you modify the above to display  the `Loading` text after you click the *Refresh* link?

Also, assume you can accomplish the same if the link was outside the <turbo-frame-tag> using the `<data-turbo-frame>` attribute?

David Kimura PRO said 3 months ago on Hotwire Dashboards :
  johnpitchko For the loading text, I would probably introduce something like a spinner instead of changing the content text.

# css
.spin {
  -webkit-animation: spin 2s linear infinite;
}

@-webkit-keyframes spin {
  0% { -webkit-transform: rotate(0deg); }
  100% { -webkit-transform: rotate(360deg); }
}

@keyframes spin {
  0% { transform: rotate(0deg); }
  100% { transform: rotate(360deg); }
}

Added a stimulus controller called refresh which will add the spin class when clicked on

# show page
<%= link_to reload_icon, weathers_feels_like_path, class: "float-end", data: { controller: 'refresh' } %>

# refresh_controller.js
import { Controller } from "@hotwired/stimulus"

// Connects to data-controller="refresh"
export default class extends Controller {
  connect() {
    this.element.setAttribute("data-action", "click->refresh#click")
  }

  click(e) {
    this.element.classList.add("spin")
  }
}

This works because the entire turbo frame tag will be replaced. So, when the link is clicked, it will start spinning. Once the response is rendered, the link (as well as the entire turbo frame tag) will be replaced and it will "appear" to stop spinning.



johnpitchko said 3 months ago on Hotwire Dashboards :
Thanks   David Kimura  I was hoping there was an easy non-Stimulus/JS solution (as I haven't dug into Stimulus yet). Maybe there is but you're solution is probably fine. I will experiment with your solution and see what I come up with!

David Kimura PRO said 3 months ago on Hotwire Dashboards :
To make the stimulus controller (especially if you're using importmaps or esbuild), you can use the task

bin/rails g stimulus refresh

konung PRO said 3 months ago on Hotwire Dashboards :
Had to go down the rabbit hole -  couldn't figure out why my calls to openweathermap.org weren't working and freezing application for 60 seconds (until requests timed out)
This issue was in weather_service.rb for anyone else having the same issue.


Login to Comment