feat(address): add component

[tatimblin]

renders an address based on the format specified in lines. Falls back to official localized address format

J=SLAP-2441
TEST=auto

[tatimblin]

Code Coverage / call_code_coverage / base-coverage
Is expected to fail because there is no previous run to compare coverage to

Percy Snapshots / call_percy_snapshots / percy_snapshots
Is expected to fail because Storybook isn't added yet

[yen-tt]

I noticed eslint in this repo is using slapshot version, should this be using '@yext/eslint-config instead? If not, can you update the config to extends '@yext/slapshot/typescript-react' instead of '@yext/slapshot/typescript

[tatimblin]

I noticed eslint in this repo is using slapshot version, should this be using '@yext/eslint-config instead? If not, can you update the config to extends '@yext/slapshot/typescript-react' instead of '@yext/slapshot/typescript

resolved in other commit that edited that line #2 (comment)

[oshi97]

when would fieldName === ',' be true? little confused why fieldName would be a comma

[tatimblin]

Commas are an additional "type" in AddressPart to be specified in the lines prop. So lines: [['line1', ',', 'line2']] would look like this "123 Main Street, apt #2" while lines: [['line1', 'line2']] would look like this "123 Main Street apt #2". The purpose of this is although extremely uncommon clients will have particular points about where the commas in an address should go and not go.
Would not be opposed to building the commas in and making customizing where they go as out of scope

[yen-tt]

can you add slapshot linting github action to this repo as well?

[tmeyer2115]

Looking at the Address Component, I think there are a number of foundational issues. That's no knock on this PR! We're porting the Component over from PagesJS. The Component represents the format of an Address as a matrix. I can see why someone chose to do it that way, but it's not intuitive. It certainly won't feel intuitive to an external developer who wants to alter the format. Likewise, I don't think htmlProps is especially intuitive either.

For now, I think we should remove lines, seperator, and htmlProps from the Address interface. I don't think they make for a good customization experience for the developer. Also, by removing these props, we're free to change the implementation of the Component. We can get away from the "format as matrix" paradigm. Implementation-wise, I think we'd also want to look for a 3rd party library to do the localization instead of a manually maintained mapping.

With this PR, we'll have an Address Component that produces the canonical, localized form of an Address. We can then talk with Product about how much customization we should allow in this Component and how.

[oshi97]

do you think we'll ever need other address from the Address type, or will we always only use the countryCode?

[tatimblin]

it's only for countryCodes

[oshi97]

Maybe this component would just take in the countryCode as a prop instead of the whole Address? If we think long term it will only ever need countryCode

[tatimblin]

It needs the other ones to print as the address. The function localeAddressFormat() just happens to only need a countryCode

[tatimblin]

The Component represents the format of an Address as a matrix. I can see why someone chose to do it that way, but it's not intuitive. It certainly won't feel intuitive to an external developer who wants to alter the format. Likewise, I don't think htmlProps is especially intuitive either.

I removed but to specify these

I like the lines matrix because it lets you build any format which protects from weird client requirements.

For htmlProps a developer wouldn't actually interact with this. All it means is that you can do things like
<Address id="someId" ariaLabel="someName" ariaExpanded="true" style={someStyles} onPopState={() => {}} />
and any other HTML attribute allowed on a div, without having to specify all of them.

[oshi97]

prettier will come later right?

[oshi97]

is this something we want to include in this library? it seems like a pretty specific opinion on how to format addresses?

[tatimblin]

Every country has an official or culturally popular format for how an address is formatted, so this is useful for that. Consider a US vs Switzerland address. The US has many cities with the same name so state names are crucial. Switzerland geographically is much smaller and doesn't even have states/regions. Even if all the document.address data is provided, it is important that we present the information in a way end users are familiar with.

[tmeyer2115]

@oshi97, I wouldn't say these are opinions exactly. They represent the canonical address format for a particular locale or country. In France (or Switzerland) addresses don't follow the US format. Going forward, I think we should find a third party library to do this for us. Manually maintaining this ourselves seems like we're making life unnecessarily difficult.