Licensing Portal: Add company details form

[kallehauge]

Summary

This PR aims to add a new page to the Licensing Portal where partners can update their company details like company name or company address, so they have up-to-date information on their invoices.

Changes proposed in this Pull Request

• Add a new page Company Details page (/partner-portal/company-details).

Context

• 1201902532330136-as-1201955149001159
• pdpAdu-bj-p2

Testing instructions

Submit new data

• Apply D79508-code and point your DNS to your sandbox
• Spin up the branch
• Go to http://jetpack.cloud.localhost:3000/partner-portal/company-details
• Add address information (could be Automattics address)
• Submit the form and (hopefully) you should now see a success message
• Hard refresh the page to check if the data was persistent

Tracking

• Verify that your submission shows up in tracks as a calypso_partner_portal_update_company_details_submit event (there might be a 10min delay): 2c4d2-pb

Screenshot

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-34296

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-34296&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~47 bytes added 📈 [gzipped])

name           parsed_size           gzip_size
entry-stepper       +204 B  (+0.0%)      +47 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~1442 bytes added 📈 [gzipped])

name                          parsed_size           gzip_size
jetpack-cloud-partner-portal      +5557 B  (+1.3%)    +1442 B  (+1.1%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[atanas-dev]

The dropdowns can go out of bounds on mobile when closed:

[atanas-dev]

Let's stick with camelCase when dealing with data inside Calypso so API responses are API* interfaces (e.g. APIPartner) which we transform into camelCase interfaces (e.g. Partner) immediately upon receiving them and we flip them to snake_case when we send requests. It's annoying but it also helps to differentiate API data vs internal Calypso data and with being consistent in both environments in terms of naming conventions.

[kallehauge]

I'd love to get your take on this direction: 736ec3e (the actual implementation gives TS errors because I'm messing with the interface values. I guess I could work around it by defining the properties as <unknown> first 😅 )

When we format the partner, we convert it to postalCode so it will be camelCase when we work with it in the code itself, but we keep the payload as postal_code.
I kinda like the idea of specifying the exact payload we need to provide + doing it this way we don't have to convert the value in 2 places:

• mutationUpdateCompanyDetails as highlighted here.
• When we record the calypso_partner_portal_update_company_details_submit track - the track expect snake and/or kebab case formatting).

[atanas-dev]

The way I think about this is based on what is internal and what is external.
Anything in Calypso should be in Calypso's format. Anything coming in from the "outside" or going out should be in whatever format the "outside" in that case uses.

As such, JSON coming in from the WPCOM API is in snake_case and when it enters Calypso's domain, it should be converted to an appropriate format for Calypso.
When data needs to go out to the WPCOM API it should be in snake_case as that is what the API uses, even if that means we have to convert it back to snake_case.
The same logic applies to Tracks - it's an "outside" domain and we need to convert it if that is what that domain expects.

For argument's sake, let's say that Stripe used kebab-case and Tracks used MACRO_CASE - which one would we use? Would we allow our Calypso state to be littered with 4 different cases because of where that data originally comes from? Even if that data comes from someplace else the moment it enters Calypso's domain, it becomes Calypso's data and should be treated as such.

Isolating and converting data's structure at the entry and exit points makes the most sense to me, even if that means some extra work on converting the data's structure on the way in and on the way out.

[kallehauge]

I have re-ordered some of the fields to better match the i3 "create partner" experience (p1HpG7-fQT-p2)

[atanas-dev]

Some replies on outdated files are appearing on their own instead of in their threads so I think you'll have to expand the previous set of feedback items in order to see the full context 😩

[atanas-dev]

I've taken over the task and have addressed my feedback.

[heydemoura]

LGTM

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/7331543

Thank you @kallehauge for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.