-
Notifications
You must be signed in to change notification settings - Fork 54
[Claim refactor index] - Part 1 - Extrapolate 5 small components (summary, nav, claim messages) #2072
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, although PR deployment didn't trigger so I did not test the flow
ebc4872
to
91e7773
Compare
|
Tried it out now, flow looks the same 👍 |
91e7773
to
8ed0258
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice you broke it down, thanks for refactoring, however not so fan of the current approach.
Anyways, we will move forwards and try to make this look more similar to other components of the app (use redux state) and simplify the state (i.e. don't add so many booleans for mutually exclusive state
import { IntroDescription } from './styled' | ||
import { ClaimCommonTypes } from './types' | ||
|
||
type ClaimIntroductionProps = Pick<ClaimCommonTypes, 'hasClaims'> & { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is all this better than adding just a hasClaims: boolean
if we use the approach i sugges:
CONS:
- yes if
hasClaims
change type, it will be automatic
PRO
- Way easier to read
- More self contain component. You don't need to artificially get some other type to get a field from it
8ed0258
to
c99d373
Compare
Summary
Extrapolates some
claim > index.ts
code into 5 small components (summary, nav, claim messages)Uses the claim context to make this easier
Can be tested by just using the claim flow. same info should show as
claim
build