Page MenuHomePhabricator

[landing] introduced modal boilerplate
ClosedPublic

Authored by ginsu on Oct 10 2022, 11:32 AM.
Tags
None
Referenced Files
Unknown Object (File)
Apr 6 2024, 5:57 PM
Unknown Object (File)
Mar 28 2024, 10:05 AM
Unknown Object (File)
Mar 28 2024, 10:05 AM
Unknown Object (File)
Mar 28 2024, 10:05 AM
Unknown Object (File)
Mar 28 2024, 10:05 AM
Unknown Object (File)
Mar 28 2024, 10:04 AM
Unknown Object (File)
Mar 28 2024, 9:59 AM
Unknown Object (File)
Mar 25 2024, 4:37 AM

Details

Summary

Implemented the necessary boilerplate with the modal provider/context

Next diffs:

  1. Clean up investor profile card modal UI to reflect the design on the figma
  2. Populate investor cards with data

Linear Task: ENG-1953
Figma: Investor Page

Depends on D5328

Test Plan

Please view the attached video to see how the modal looks and acts visually:

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ginsu edited the test plan for this revision. (Show Details)
ginsu added reviewers: atul, abosh, rohan.
landing/landing.react.js
23 ↗(On Diff #17455)

Used the app component in web as inspiration

landing/modal-provider.react.js
1 ↗(On Diff #17455)

Used the Modal provider in web as inspiration

landing/modal.css
1 ↗(On Diff #17455)

Used the Modal styles on web as inspiration

landing/modal.react.js
1 ↗(On Diff #17455)

Used the Modal Component on web as inspiration

Looks like we're essentially duplicating the Modal component that we have in web. I guess we can't easily share components across web and landing in lib?

CC @ashoat, @tomek for thoughts

This revision is now accepted and ready to land.Oct 12 2022, 10:00 AM

We can totally share components between web and landing in lib

okay sg, I'm thinking the best way forward is to create a new task to refactor the modal component into lib. I'll work on that and once that task is finished, I will rebase and change this diff to use that component. Lmk if you disagree with this gameplan

tomek requested changes to this revision.Oct 13 2022, 7:51 AM

We can totally share components between web and landing in lib

It might be right, but I think we can encounter some issues because lib is also used by native. But still, it is definitely worth trying.

landing/investor-profile.react.js
19 ↗(On Diff #17455)

It's better to use semantic HTML, e.g. a or button when we have onClick

landing/landing.react.js
84–100 ↗(On Diff #17455)

Not sure how this will look like, but it feels like there isn't a good reason for introducing a new component and instead we can render the provider inside the existing one

landing/modal-provider.react.js
1 ↗(On Diff #17455)

In files that were inspired, could you highlight what was changed compared to the original ones?

This revision now requires changes to proceed.Oct 13 2022, 7:51 AM

resovled tomek's comments + use modal components from lib

ginsu retitled this revision from [landing] introduced modal component and boilerplate to [landing] introduced modal boilerplate.Oct 14 2022, 2:21 PM
ginsu edited the summary of this revision. (Show Details)
ginsu edited the test plan for this revision. (Show Details)
landing/landing.react.js
98–106 ↗(On Diff #17594)

@tomek I know you made comments not to introduce the LandingWithProvider component; however, when I got rid of this component, the modals stopped working for landing. My working theory is that ModalProvider needs to be above modalContext in the DOM tree in order for modalContext to get the modals value. Web follows this same pattern too. I will keep investigating more over the weekend, and if I find anything helpful will add a comment to this thread, and if you have any ideas too, please let me know!

Accepting, because the diff looks ok. The refactoring I proposed can be done as a separate task / diff.

landing/landing.react.js
98–106 ↗(On Diff #17594)

You're definitely right - modalContext has to be inside the provider.

One solution is to modify ModalProvider to render the modals instead of only exposing it to its descendants. So the provider could render something like this

  const modalNodes = React.useMemo(
    () =>
      modals.map(([modal, key]) => (
        <React.Fragment key={key}>{modal}</React.Fragment>
      )),
    [modalContext.modals],
  );
...
<ModalContext.Provider value={value}>
  {children}
  {modalNodes}
</ModalContext.Provider>

An additional benefit is that the main landing page no longer needs to know implementation details of the provider to use it correctly. Also, not exposing modals from the context may improve the performance. The downside is that the provider decides where to render the modals and it can't be in any place of the app - that doesn't hurt us at the moment.

The same approach could be also used on web (and probably should be used from the beginning).

This revision is now accepted and ready to land.Oct 17 2022, 1:36 AM
This revision was automatically updated to reflect the committed changes.