Theo's Typesafe Cult•3w ago

AITA? - Swapping components in-place with state in React Native

I’m a junior-level frontend developer. I’ve been with my company for only a year and this is my first job as a frontend dev. I was hired to help write our new app, as the one we were using was a template app maintained by a vendor. We’re writing the new app in React Native and it feels very nice to be able to create native interfaces using JSX and syntax I already know from personal projects. We’re using Expo, React Native Paper, React Navigation, etc. My question is this: I’m one of two people working on the frontend of the app. My coworker tends to use a special pattern when designing linear flows of screens for sign-in, forms, or really anything. Here's a generalized example of what a “Flow” component looks like:

export const ProcessFlow = () => {

  const navigation = useNavigation();

  const [processStep, setProcessStep] = useState(0);

  const getStepComponent = (step) => {
    switch (step) {
      case 0:
        return <StepOne goToStepTwo={() => setProcessStep(1)} />;
      case 1:
        return <StepTwo goToStepThree={() => setProcessStep(2)} goToStepFour={() => setProcessStep(3)} />;
      case 2:
        return <StepThree goToStepFour={() => setProcessStep(3)} />;
      case 3:
        return <StepFour exitFlow={() => navigation.goBack()} />;
      default:
        return null;
    }
  }

  return (
    <View>
      {getStepComponent(processStep)}
    </View>
)};

export const ProcessFlow = () => {

  const navigation = useNavigation();

  const [processStep, setProcessStep] = useState(0);

  const getStepComponent = (step) => {
    switch (step) {
      case 0:
        return <StepOne goToStepTwo={() => setProcessStep(1)} />;
      case 1:
        return <StepTwo goToStepThree={() => setProcessStep(2)} goToStepFour={() => setProcessStep(3)} />;
      case 2:
        return <StepThree goToStepFour={() => setProcessStep(3)} />;
      case 3:
        return <StepFour exitFlow={() => navigation.goBack()} />;
      default:
        return null;
    }
  }

  return (
    <View>
      {getStepComponent(processStep)}
    </View>
)};

Of course, this code causes the entire root component to re-render when the processStep state changes. The problem I’ve been trying to appeal to him is that in native terms, this swaps the content of the component in-place and does not transition anything in or out and may be lacking some accessibility features (although I haven’t tested it myself and from what he’s shown me, screen reading / control aren’t specially affected). I prefer to use the stack navigators from React Navigation when building my flows, but we’re running into the problem of one dev doing one thing and another doing something different and creating experiences that look different. My main rationale for using proper navigators is so that users have a spatial understanding of where they came from and where they went. This is a problem I used to notice (especially with older folks who will be a large portion of our app's users) in my tech support days in the phone sales industry. Obviously I also want the app to just look and feel right, and to not feel like the "poorly wrapped webview" that React Native is accused of being by non-devs I also tried pitching the idea of using a custom hook to generate a stack navigator on the fly with an array of child “steps” that can receive injected “prev()” and “next()” props to control the flow from within the steps. The result of that hook would then be rendered as a child. So the paradigm of going between steps is preserved but the screens actually transition in and out properly and the native look and feel is present. This was also shot down. In his words, it adds too much complexity for little to no value. I’m having a bit of an personal crisis with this, because I can’t tell if I’m wrong and I’m nitpicking over what’s essentially nothing, or if I’m right and this is something I have to overcome with him or just sit on my hands and ignore until after launch day when we can shift things easier. To note, I’m looking at this strictly from a look and feel perspective. As far as I’ve seen, no extra re-renders or bugs have come from this. The screens themselves do not alter the state and only call the goTo functions when they’re done. We also tend to wrap these flows in contexts if the steps need to share data. Any advice at all would be very helpful.

2 Replies

chrisyates.devOP•3w ago

Also I bought nitro for this plz send mental help

chrisyates.devOP•3w ago

Here's a better highlighted view of the component

Gaming

Programming

AITA? - Swapping components in-place with state in React Native

Did you find this page helpful?