-
Notifications
You must be signed in to change notification settings - Fork 261
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
Applying ADA filters for the Map view of search. #651
Applying ADA filters for the Map view of search. #651
Conversation
Looks good, thanks! I'll take a closer look at the code, but mostly I'll be relying on the tests and a manual functional check using either Docker or Heroku. Would be great to have this all working together. |
list.fadeOut(500, function() { mapContainer.fadeIn(500, initPoints) }); | ||
} | ||
mapShow = !mapShow; | ||
// Polyfill for Poltergeist. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do hope to support most older browsers. As long as it's reasonably easy to do so.
I guess Poltergeist is the one that needs to work for testing purposes... but this comment can probably say "Polyfill for older browsers"? As we don't have Poltergeist when running in Heroku/production/the real website.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes @DeeDeeG you're right!
I'll change this to old browsers
as it fits better!
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An update on the review process: I'm hoping to get the rubocop pull request (#644) merged first thing, then come back to pull requests such as this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure @DeeDeeG ! No rush!
Good news, this has no merge conflicts with I'm also happy to report this passes our automated testing (Travis CI). I'll run this through some manual functional tests, and if all looks good, that's the last thing to "check off" before merging. Thanks for the contribution, once again. Testing as hosted here: https://refuge-deedeeg-test.herokuapp.com/ |
Hi @GPrimola, I noticed in my testing that the info bubbles are popping up blank on this branch. This branch (https://refuge-deedeeg-test.herokuapp.com/):
Are you able to look into this and see if there is a way to make the popups show their content again? Thanks. - DeeDeeG |
Sure @DeeDeeG !! Sorry to ask, but do you think this is related to this changes? Because thinking very shallow here, it doesn't make much sense this changes would introduce this kind of behavior. But sure I can check what's going on! |
@GPrimola that is a fair question. I just double-checked in case I was mistaken (it happens). I have an instance of Heroku for this branch exactly: https://refuge-deedeeg-test-2.herokuapp.com, and this branch with the Rubocop changes (the tip of the Both instances have the blank info popups. And The only difference is the two commits on this branch. So I am fairly confident the changes in this branch are causing the different behavior on the site. |
Perfect @DeeDeeG !! I'll check it this weekend and push the changes by monday! |
@DeeDeeG I just pushed some changes that fixed the problem. Can you check if it's ok? Thank you! |
@GPrimola It's working, thanks very much for posting and addressing review comments on both of these pull requests. |
@GPrimola If you are interested, I think it would be nice to make it so that switching from list view to map view and back doesn't require a page reload. (It makes some sense that changing the filters could require a new page load, due to needing a new API call to get the new set of restrooms matching the new filters. But once we have a set of restrooms on a page, I believe we have enough data loaded to switch from map view to list view and back.) But this pull request is already quite good as it is, and that would be extra if you decide to take it on. And I completely understand if you don't want to. It already works well the way it is. For now, I'll merge this the way it is. Thanks again. |
* Finish Upgrading Webpacker to v5 (#637) - Gemfile[.lock]: Update webpacker to 5.2.1 - Webpacker: Update config files Ran "rails webpacker:install" and committed the changes. In "config/webpacker.yml," kept the ".js.erb" entry under "extensions:" so that "app/javascript/packs/lib/maps.js.erb" is included. In "config/webpack/environment.js," kept jQuery and rails-erb-loader configs, as we are still using these. - JS dependencies: Upgrade webpack-dev-server Commit the changes from running `rails webpacker:install`, but using a caret "^" semver range for "@rails/webpacker", rather than an exact version. (So that we get updates in the 5.x series) * Update dependencies for September 2020 (#636) - dependencies: Remove `swagger` node module We don't actually use this. Also removes 200 sub-dependencies, and makes our yarn.lock file about 1270 lines shorter! - yarn.lock: Upgrade bootstrap to 4.5.2 (Was at version 4.4.1) - dependencies: Resolve node-fetch to ^2.6.1 - yarn.lock: Upgrade "selfsigned" and "node-forge" - Gemfile[.lock]: Update Rails and dependencies rails was 5.2.4.3, now it's version 5.2.4.4 * Keeping filters state on pagination (#638) - Keeping filters state on pagination - Fix Code Climates complaints. - Fixed active issue on ada filter buttons - Fixed undefined function problem when run rspec. * Add rubocop and resolve lint errors (#644) - Initialize rubocop - Run rubocop with --fix - Don't require magic comment This will affect every file and have potential side effects, so I'm going to start with this turned off. - Resolve lint errors in `app` - RSpec linting - Resolve remaining - Fix wrong change - Singleton method for verify - New lint rules - Add rubocop to travis config - Correct docker compose command - Check for geo The condition was actually supposed to be `if geo = results.first`, because that's not always obvious the intention and fails lint, I'm just doing a truthy check for it which should be the same. - Fix typo - Add contributing docs for rubocop * Applying ADA filters for the Map view of search. (#651) - Applying ADA filters for the Map view of search. - Changed comment for polyfill URLSearchParams - Fixed bug of map marker content not showing. * Add a standard EditorConfig configuration for every contributor to follow (#649) * Enhancement/i18n thread safe (#647) - Provide a way to respond requests without thread-safe issues As rails docs says https://guides.rubyonrails.org/i18n.html#managing-the-locale-across-requests When we use 'I18n.locale =' the current locale could leak into following requests this is a standard and recommended way to deal with it :) - Create a shared_example to test I18n locale switching - Update spec/controllers/pages_controller_spec.rb * Upgrade puma to latest version 5.x (#641) * yarn.lock: Update "http-proxy" to v1.18.1 (fe195d7) Co-authored-by: Lucas <torres.giorgio@gmail.com> Co-authored-by: Tegan Rauh <3896310+tegandbiscuits@users.noreply.github.com> Co-authored-by: Bruno Casali <brunoocasali@gmail.com>
Context
Summary of Changes
@view
holding one oflist
ormap
values.index.html.haml
had to be changed to show the list view or the map view of the search restrooms.index.js
was changed with a new logic to support the new behavior when loading the map.Checklist
Screenshots
Before
After