things i learned about the React ecosystem by

building without them

Wei / RK #64 / feb 28 2020

i've been building

a site generator

- packing

- serving

- creating the app

- routing

- a few critical functionalities and components

initial approach

striped off from someone else's existing project

 

along the way

re-examine each part and determine how exactly we want it to function

turns out our project is also

free of

class components & Redux

so far

today we're talking about a few of the problems I encountered thus far

1. document title

easy right?

document.title = "react knowledgeable"?

import * as React from 'react';

const useTitleNaive = title => {
  React.useEffect(() => {
    document.title = title;
  }, [title]);
};

export default () => {
  useTitleNaive('hello!');
  return <>title should be "hello!"</>;
};

why u no work?

react helmet

is managing the relevant tags

problem 1

setting title is a global side effect that persists

problem #2

Text

when multiple <Title /> components (or equivalent hooks) are mounted, it is hard to reason who wins

problem #3

import * as React from 'react';

const useTitleNaive = title => {
  React.useEffect(() => {
    document.title = title;
  }, [title]);
};

const Component = ({ title }) => {
  useTitleNaive(title);
  return <div>component sets the title to {title}</div>;
};

export default () => {
  useTitleNaive('page');
  return (
    <>
      page sets title to "page"
      <Component title="component" />
    </>
  );
};

import * as React from 'react';

const Title = () => {
  const useTitleNaive = title => {
  React.useEffect(() => {
    document.title = title;
  }, [title]);
};
}

const Component = ({ title }) => {
  return <div>
    <Title>{title}</Title>
    component sets the title to {title}</div>;
};

export default () => {
  return (
    <>
      <Title>Page</Title>
      page sets title to "page"
      <Component title="component" />
    </>
  );
};

how do other people do it?

another internal project

update title on every page

it's side effect with respect to React, but a feature in our app

how does

React Helmet

do it

we need to talk about React Side Effects

key concept

allows you to work on

all instances

of a component as a whole

so you can

determine who wins

when you have multiple <Title /> components

there's only 92 loc

what happens under the hood

  • componentWillMount, componentDidUpdate: emitChange()
  • componentWillUnmount: remove the instance and emitChange()
  • emitChange():
    • calls reducePropsToState for you to turn relevant props to state
    • calls mapStateOnServer to execute side effects

recap

  • handles side effects from all instances of a component altogether
  • allows users to define a winning prop after iterating through all instances
  • acts in 2 phases
    • reduce props to state
    • execute side effects (client or server)
  • relies on class components' static properties

typical usages of

React Side Effects?

Dan Abramov:

React Document Title

solution we went for

arguably desired behavior for my project

> layout renders a “default” title, which individual pages and / or components can then overwrite

> leaving the page or unmounting the component “resets” the title back to a “clean state”

- <Title /> runs a side effect hook to set document title

- <Layout /> renders a <Title /> on every page with a default title, more nested <Title /> takes precedence

look back in this journey

- setting document title as a global side effects

- dealing with the side effects for a class of components together

- sometimes we may find easier solution because we have more assumptions about our projects

2. state management

regarding the huge battle

redux or not

  • we wanted to be un-opinionated
  • that actually means we build our core without reliant on Redux

page 1

page 2

page 3

user

app core

badges

app core

const useBadge = (id, text) => {
  const { badges, setBadges } = useContext(BadgeContext);
  useEffect(() => {
    setBadges({...badges, [id]: text});
  }, [id, text])
};


const MyPage = () => {
  useBadge('weather', 'raining');
  useBadge('notification', '2');
  return (<>
    <Badge id="weather" />
    <Badge id="notification" />
  </>);
};

the 2nd setBadge call will overwrite the result of the 1st call with the old state with the 2nd new badge only

use useReducer to decouple action with update logic

const reducer = (state, action) {
  switch (action.type) {
    case 'new badge': {
      return {
        ...state,
        [action.id]: [action.text]
      };
    }
    default: {
      throw new Error();
    }
  }
}

const MyPage = () => {
  const [, dispatch] = useReducer({});
  dispatch({type: 'new badge', id: 'weather', text: 'rainy' });
  dispatch({type: 'new badge', id: 'notification', text: '2' });
  return <>
    <Badge id="weather" />
    <Badge id="notification" />
  </>;
}

some pseudocode

badges

app core

user

now we have multiple states live inside separate contexts, each managed by `useReducer`

badges

app core

user

sider collapse state

current route and params

?

event system

dispatch / subscribe with payload

we use dispatched events with payloads as a bridge for communication

// core library

const Layout = () => {
  useEffect(() => {
    return subscribe('debug', ({page}) => { 
      console.log(`debugging ${page}`) 
    });
  }, []);
  return // route-based page loader
};
// page
import { dispatch } from 'outerspace-headquarter';

const MyPage = () => {
  dispatch('debug', { page: 'my page' })
  return <div />
};

each communication pathway connects an interaction to a callback, but most of the time, the callback sets payload to an internal state

- multiple stateful variables w/ useReducer

- event system

maybe we should just bring Redux back

someone created an issue:

persist data between pages

the request goes

“can we have something similar to <keep-alive /> of vue.js”?

https://github.com/facebook/react/issues/12039

“Keep data cached separately from the component. For example, you can lift state up to an ancestor that doesn't get mounted, or put it in a sideways cache like Redux.”

- Dan's comment

changing part of the store does not change other part... kind of serves as a temporary storage cross the SPA

thoughts around <keep-alive />:

  • Hoist the data to a parent component
    • not practical cuz props drilling
  • Via state management such as Redux (next slide)
  • Maintain data in a separate stateful variable, put it in context, and access with hooks
  • Put data somewhere else and retrieve with hooks
    • flexible storage of data

is Redux “too heavy”?

- redux is tiny

- react redux not big neither

- the work needed to make Redux work with our apps

routing, code splitting, SSR...

Redux-y things we do anyway

- individual reducers in context

- events

Redux-y things we miss

- separate data states with app states

but, we may not want to bring back Redux because we don't want our app to be so centralized

page 1

page 2

page 3

listing

detail

edit

page 1

page 2

page 3

user

routes

ui states

app core

3. loading + navigating

flash of loading component

https://tdvim.csb.app/

React Loadable:

wait a short amount of time before displaying the loader component

but it will still flash a white screen when `null` is being rendered

so how ah

const App = () => (
  <main>
    <Router>
      <Loader path="/cat" key="/cat" />
      <Loader path="/dog" key="/dog" />
    </Router>
  </main>
)


const loaderMap = {
  "/cat": () => import("./cat"),
  "/dog": () => import("./dog")
};
const Loader = ({
  path,
  loader,
  children
}) => {
  const [module, setModule] = React.useState(modules.get(loader));
  React.useEffect(() => {
    if (!module) {
      fetchModule(path, loader).then(mod => {
        setModule(mod);
      });
    }
  }, [loader, path, module, setModule]);

  if (!module) {
    // this _will_ result in a flickering before the 1st time the component is loaded
    return null;
  }

  const { default: Component, ...rest } = module;

  return <Component {...rest}>{children}</Component>;
};

still ffffflickering...

arguably more finely controlled behavior: preload component before navigating

> preload / prefetch is more of navigating logic than of loading logic

> so loaders aren't really supposed to take care of this... (at least not yet, with the React ecosystem)

const fetchThenNavigate = path => e => {
  e.preventDefault();
  fetchModule(path).then(() => navigate(path));
};
const fetchModule = async (path, customLoader) => {
  if (modules.get(path)) {
    console.info(
      `%cModule ${path} already loaded`,
      `color: #82aaff;${commonLogStyles}`
    );
    return modules.get(path);
  }

  const loader = customLoader ? customLoader : window.loaderMap[path];

  if (!loader) {
    throw new Error(`Didn't see a loader`);
  }

  console.log(`%cLoading ${path}`, `color: #addb67;${commonLogStyles}`);
  return loader()
    .then((module: any) => {
      console.info(`%c${path} loaded`, `color: #22da6e;${commonLogStyles}`);
      modules.set(path, module);
      return module;
    })
    .catch((err: string) => {
      console.error(err);
    });
};

> not to confuse with html's prefetch / preload attribute though

> PRPL Pattern is also a thing

you can use a loader fn that returns a promise, and wait for that promise to fulfill before you navigate

React Loadable provides this function, but says it creates bad user experience

to create the wheel...

  • we have more assumptions to leverage on so we can stick to simpler solutions
  • we have special requirements that are not addressed by existing libraries

or not create

  • we end up solving the same problems
  • we come down to canonical solution

such a big topic, i'm scared of Q&As

Made with Slides.com