platform dashboard

[kialj876]

Issue:

• bcgov/entity/issues/

Description of changes:

• Renaming of connect form components is an ask from the connect repo PR (let me know if this is in line with what you were thinking)
• dashboard work is in progress (several things I still need to do), but I was hoping you'd have a look at the way I'm doing the 'DetailsHeader' in the layout and setting the values via a connect store. Was thinking we would update the button control / breadcrumbs to do it this way as well instead of adding custom page meta values, but have a look and see if you like it
• new page path: .../platform/registration/:regId
  • example with real dev platform registration: https://strr-platform-dev--pr-202-kinxn4mf.web.app/en-CA/platform/registration/131

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

[bcregistry-sre]

Temporary Url for review: https://strr-platform-dev--pr-202-kinxn4mf.web.app

[deetz99]

1. component renaming looks good to me

2. This is something I'm still mulling over myself, what the best way to go about this is (including breadcrumbs/button control). One thing to keep in mind is if different people are using the layer we might want to add some flexibility. For example, do we add props to all these components, and set the props in the layout files using the route meta (if people want to make custom layouts, we aren't forcing them to use the route meta this way) or do we get rid of the page meta entirely and only rely on props/store values?. One thought I had was to add props to the components and keep the setBreadcrumbs/setButtonControl utils and then also have a store usePageMetaStore where we would handle all the state utilizing the page meta utils we have. This way we could allow only props or only page meta or only store values to manage the state. Downside is we would have to pass the values in whenever creating a new layout and maybe it's overkill and we should be forcing people to use it in a certain way?. Anyways, I don't see any issue with using the store for strr but we'll want to think about this if pulling it into the layer.

3. 👍

[bcregistry-sre]

Temporary Url for review: https://strr-platform-dev--pr-202-kinxn4mf.web.app

[bcregistry-sre]

Temporary Url for review: https://strr-platform-dev--pr-202-kinxn4mf.web.app

[bcregistry-sre]

Temporary Url for review: https://strr-platform-dev--pr-202-kinxn4mf.web.app

[bcregistry-sre]

Temporary Url for review: https://strr-platform-dev--pr-202-kinxn4mf.web.app

[sonarqubecloud]

Quality Gate passed

Issues
14 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[bcregistry-sre]

Temporary Url for review: https://strr-platform-dev--pr-202-kinxn4mf.web.app

[deetz99]

Is this correct? 'text-lg' is 18px

[kialj876]

I think so? We've got H1's as 1.25rem (20px) and H2's as 1.125rem (18px) in many places. The explicit '-32px' / '-24px' were originally from the strr-web project

[kialj876]

I could be wrong about this for sure though

[kialj876]

Okay after looking at the other apps I think this is supposed to be 2rem for H1 and 1.5rem for H2, and then we can just override it for other cases where it varies

[deetz99]

Just a few minor comments but everything looks great!