department-of-veterans-affairs / va-mobile-library

https://department-of-veterans-affairs.github.io/va-mobile-library/
ISC License
0 stars 0 forks source link

DS - Tech Discovery for Loading Component #248

Closed kellylein closed 1 month ago

kellylein commented 3 months ago

Description

This story is to look at the Loading Component to determine any technical complexity we will need to account for during development.

Important links

Design updates

Acceptance Criteria

- [ ] Determine the variants needed for the component - [ ] Identify and areas that need discussion with the team for MVP scope - [ ] Create stub stories for any 1-off things needed for the component
narin commented 1 month ago

Loading Indicator Tech Discovery

1. On a scale of 1 to 5, how much does the new component differ from the original? How much of the existing code is reusable? Explain technical differences.

4

The new component acts not only as a loading indicator, but an error message and success/empty message. This will require additional props for each state. Additionally, existing code uses a 3rd party library for animating the loading indicator which may need to be replaced. See question 5 for more info. Due to the changes mentioned, only a small amount of the existing code may be reusable, mainly around styling for center vertical and horizontal alignment.

2. Are there any changes or optimizations that could be made to the existing component that would be applicable to other apps and/or make developer's lives easier?

As mentioned above, props will need to be taken into consideration for each of the possible states of the loading indicator. The existing component also does not have any analytics which will be useful for reporting error, empty, and success states.

3. What are the differences between the new component and the VADS web equivalent? Do the differences warrant a separate/different component?

The loading state looks visually the same as VADS web, but it will also include error and success states as mentioned. Additionally the mobile version will also have an inline variant. I don't think the additional variants warrant a new component.

4. To the best of your knowledge, does the new component cover all existing use cases in the VA Mobile App?

Yes

5. Does the component require any third-party dependencies or native functionality? If so, what would be the level of effort in coding this internally instead?

The existing component currently uses lottie-react-native to display the animated SVG. We have not determined the best way to implement native 3rd party libraries into the design system repo yet. However this plugin may not be needed and we can use React Native's built-in Animated library for simple animations such as the rotation needed for the spinner.

The web's CSS to animate the spinner may be helpful to reference:

.loading-indicator::after {
    content: " ";
    display: inline-block;
    width: 3.5rem;
    height: 3.5rem;
    border-top-style: ;
    border-top-width: ;
    border-right-style: ;
    border-right-width: ;
    border-bottom-style: ;
    border-bottom-width: ;
    border-left-style: ;
    border-left-width: ;
    border-image-source: ;
    border-image-slice: ;
    border-image-width: ;
    border-image-outset: ;
    border-image-repeat: ;
    animation-timeline: auto;
    animation-range-start: normal;
    animation-range-end: normal;
    margin: 1px;
    border-radius: 50%;
    border-color: var(--vads-color-primary) transparent var(--vads-color-primary)
    transparent;
    animation: 1.5s linear 0s infinite normal none running spin;
}

Possible code snippet: React Native: How do you animate the rotation of an Image?

6. Are there any major unknowns about the technical implementation of the component?

Replacement or implementation of the lottie-react-native plugin with react native built animation as mentioned above

7. What accessibility challenges might the new design present?

Screen readers should probably announce the change in state. For example if a screen takes a long time to load and then displays an error or empty message, we'd probably like the screen reader to announce that. Should check with Jessica and/or Brea.

8. Does the new component require any other components to exist beforehand? If so, do the base component(s) have be built or changed?

Requires either the Icon component or usage of react-native-svg since the specs mention that we don't want to make this indicator available as part of Icon

9. What assets or design tokens does the new component require? Are they already available? If not, where would we acquire them?

Latest version of tokens contains all the colors that we need. Need to check with Jessica about the svg for loading state. Error and Success should be available already with the ExclamationCircle and Check icons.

10. Based on the above, would you suggest any changes to the implementation tickets or the Epic estimate?

No

11. Compile any questions you may have for design (@jessicawoodin) here.

  1. Should the screen reader read announcements for updated loading states? e.g. when changing from loading to success/error
  2. Is there an existing SVG for the loading indicator?
jessicawoodin commented 1 month ago

To answer your questions:

  1. Should the screen reader read announcements for updated loading states? e.g. when changing from loading to success/error
    1. Yes, if we include the states in the component, the screen reader should announce the change. Lauren shared some documentation on how the global team approached this.
  2. Is there an existing SVG for the loading indicator?
    1. Yes! I have that prepped in Figma.

After reading through your write-up, I have some follow-up questions/comments for you:

  1. Did you happen to do any discovery on whether or not it makes sense to have the error/success/empty states within this component? I know that was an open question we had based on how the global team set it up. I’m not tied to including those states within the component and would be interested in your recommendation from an engineering perspective. We don’t necessarily have to include them just because the global team did.
  2. If it makes sense for engineering, I’m fine with including the loading indicator icon as part of the icon component. I didn’t see it in VADS’ icon component, but if it makes our lives easier, I think we could make a case for that with VADS.
narin commented 1 month ago

Discussed further in stand-up and decided that the error/success/empty states will not be part of the component and will be considered as an add-on/separate component.