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

chore: Migrate the AddressComponent to using ViewComponent #2638

Merged
merged 12 commits into from
Nov 18, 2024

Conversation

lenikadali
Copy link
Collaborator

@lenikadali lenikadali commented Nov 2, 2024

Work towards #2270

Description

This PR migrates the AddressComponent to use ViewComponent instead of Mountain View.
Updated the calls to AddressComponent as well to partners' and events' index pages.

Motivation and Context

From the issue:

mountain_view gem has not scaled at all well and has a bunch of weird issues with integrating with JavaScript.

We therefore need to migrate to a newer solution, view_component

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Breaking change (fix or feature that would cause existing functionality to change)

How Has This Been Tested?

Currently the attempt at a test in test/components/address_component_test.rb is failing.
Need to see how to display the event and partner pages in a local environment.

Huly®: PC-2637

Migrating the AddressComponent to use ViewComponent instead
of Mountain View.

Added an excluded style to .rubocop.yml because it got triggered
when committing the new component.

Updated the calls to AddressComponent as well.
@lenikadali lenikadali marked this pull request as draft November 2, 2024 13:54
@lenikadali lenikadali requested a review from kimadactyl November 2, 2024 13:54
@lenikadali
Copy link
Collaborator Author

Not sure what the appropriate name should be for the PR title between fix, docs and chore.

Happy to update the title once that's clear 🙏🏿

@kimadactyl
Copy link
Member

kimadactyl commented Nov 2, 2024

Looking good!

there's a small thing on these too that i'm unsure about - do we like having all the new components suffixed _component? it makes it easier to see whats been done, and makes it ultra clear what's being called, but im not sure how annoying itll be later on lol.

edit: i guess another q here is how much we want to improve as we go vs just getting mountain_view deprecated - hmm

Not sure what the appropriate name should be for the PR title between fix, docs and chore.

i think chore if we dont fix it up and feat if we do?

lenikadali and others added 3 commits November 5, 2024 21:09
Addresses the review comments namely:
1. Try to avoid disabling cops if we can help it.
2. As part of fixing the cop violations, we are switching
to use `sanitize` instead of `html_safe`. This way we can be
sure that user entered strings are known HTML safe tags
and attributes.
3. Opted to use hard coded values so that we don't have to call
VCR during unit tests.
@kimadactyl
Copy link
Member

kimadactyl commented Nov 12, 2024

@lenikadali i pushed this along a bit. rough process was to load up a page that has an address on it and note the error then just work throught the errors. i think the main confusion is where files should live. right now the presenter is in the root component directory and the template is in a folder - i think this is confusing and it should all live in the same place.

i've deleted the mountain_view code but now the other references to the address component need changing. does this make sense?

Edit: I've done a bit of searching and maybe its not possible to have the component .rb file in the sidecar directory, wahhh https://viewcomponent.org/guide/templates.html#subdirectory

@kimadactyl
Copy link
Member

Have tried the inline template style - what do you think? I think this is a lot easier to work with and reduces cognitive load but comes with the cost that unpacking it again means undoing this? But would we do that for something this simple?

Copy link
Collaborator Author

@lenikadali lenikadali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i've deleted the mountain_view code but now the other references to the address component need changing. does this make sense?

Yup 😎 I think that is the natural next step here. Most likely my mistake was to attempt to migrate while the mountain_view code was still in place so that was a good thing to do.

Edit: I've done a bit of searching and maybe its not possible to have the component .rb file in the sidecar directory, wahhh https://viewcomponent.org/guide/templates.html#subdirectory

Not sure about this. It looked like it could cause errors as reported here
If the test can succeed, then I would be open to that setup. It's your call 😉

Re-added the ERB component file so that there's a clear
separation of concerns. This also allows us to keep the code
easy to read; in case the template grows bigger, it will still
be readable.

Fixed the Rails/OutputSafety cop by moving the sanitize call
to within the template instead of trying to do it with the component

Also switched to using the `address` factory instead of a string
value; the value the component expects should be an instance of
the Address model and consequently the `all_address_lines` method
can be called on it.
@lenikadali lenikadali changed the title Migrate the AddressComponent to using ViewComponent chore: Migrate the AddressComponent to using ViewComponent Nov 15, 2024
@lenikadali lenikadali self-assigned this Nov 15, 2024
@lenikadali lenikadali marked this pull request as ready for review November 15, 2024 21:00
address: @partner.address
%>

<%= render AddressComponent.new(address: @partner.address) %>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lenikadali i found one more address just fyi! otherwise happy to merge if you are?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hahaha beat me to it 😄

Yes please merge 🙌

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh no theres an test fail now are you ok to fix the test?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why that is. Locally it doesn't fail though. Let me see 🤞

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Realized I was mixing the integration and controller tests 😅

Can't figure out why it is failing right now. Will look at it tomorrow with a fresher head.

@@ -131,4 +131,4 @@ Lint/SelfAssignment:
Enabled: false
Lint/RedundantCopDisableDirective:
Enabled: false

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cant work out how to get rid of this but i think more faff than its worth to remove from the commit now lol

Fixed the test failures by updating the `formatted_address`
method to use @raw_location. This had been overlooked in
its conversion to be compatible with ViewComponent usage
@kimadactyl
Copy link
Member

Woo good catch!

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.

2 participants