Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow user to specify and change location #110

Open
wants to merge 13 commits into
base: develop
Choose a base branch
from

Conversation

patrickjfl
Copy link
Contributor

Changes in this PR

This PR allows users to change location using the zone dropdown menu, ensuring that the forecasts update to the given zone. The previously selected day will be maintained, i.e. if the user is looking at tomorrow's forecast, and then changes location, they will now be viewing the new location's forecast for tomorrow.

This has been achieved by moving the location menu and forecast tabs within the Turbo Stream update for the forecast. Previously the styling of the forecast tabs was being handled with Stimulus.

This PR also allows the entire forecast view to be driven by state in the URL. Now, if the URL specifies a zone and/or day as URL parameters, the forecast for that zone and day will be displayed. If no zone is specified, Southwark will be shown as the default. If not day is specified, the forecast will default to today.

Screenshots of UI changes

Before

After

Next steps

Now that we have the zones seeded in the DB, we don’t need the JSON file.
We could and probably should do this with Stimulus, but I think that’s not necessary in what is already a large ticket, so I am leaving it for a subsequent refactor.
…r methods

Because we want to be able to navigate directly to a forecast for a given day and zone, we need our show and update methods to be set up to expect these parameters, and to set them as instance variables. We also need to specify default cases where one or both parameters are not specified.
Now that we have a method to return the selected day or else return “today”, this check is unnecessary.
Before we move our tab change handling from Stimulus to Turbo, we need to be able to calculate the CSS classes for each tab within our view component. When the tabs are re-rendering on every update, we can apply the classes from the server in Rails, in code that we have tested, rather than doing it on the fly in Javascript and relying on more expensive integration test coverage.
Now that we are re rendering the tabs as well within our Turbo Stream, we can remove the alert_guidance turbo frame, because this sits within the pollution_forecast partial.

I have also created a separate partial, `selected_day_input`, to capture the currently selected day within the form that updates the forecast to a new location. This would be messy without its own turbo frame and template, because it would require significant inline ERB.

I have also renamed forecast_tabs to pollution_forecast, to distinguish it from the UV, pollen and temperature forecast, and capture the fact that the component does not only consist of tabs (it also includes the alert guidance).
This has been superseded by our turbo stream, so is now redundant.
This extends Turbo Streams with a number of actions, including push_state, which will allow us to add query parameters for day and zone to the URL when we trigger our Turbo Stream.
Now we are in a position to test that specifying the zone and day as URL parameters is sufficient to display the forecast for the given zone and day.
@patrickjfl patrickjfl marked this pull request as ready for review November 15, 2024 13:31
@patrickjfl
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant