dev 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.
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.
AhmedNadar 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.
David Kimura 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.
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?
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)
☒ 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.
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
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.
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)
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
# 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.
Thanks ☒ 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!
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.
This is a great tutorial David! Easy way to present users with a pre-configured dashboard.
How would you extend the ability to allow a User to further customize the dashboard widgets? i.e a User can go into their dashboard to reorder and reconfigure modules with dragging and dropping, add widgets etc.
The source code for displaying random images is lost somewhere)
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.
Regarding Rails 7, have you worked with import_maps instead of jsbundling and cssbundling?
If it is possible, have an episode highlights import_maps usage and compare it to an esbuild episode.
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?
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)
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.
Also, assume you can accomplish the same if the link was outside the <turbo-frame-tag> using the `<data-turbo-frame>` attribute?
Added a stimulus controller called refresh which will add the spin class when clicked on
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.
This issue was in weather_service.rb for anyone else having the same issue.
How would you extend the ability to allow a User to further customize the dashboard widgets? i.e a User can go into their dashboard to reorder and reconfigure modules with dragging and dropping, add widgets etc.