DEV Community: Kevin Sullivan

what are the missing features on dev.to?

Kevin Sullivan — Sun, 14 Jun 2020 21:53:53 +0000

some people might want thumbs down emoji. what do you think is missing? personally, i want better topic filters. plenty of things end up in my feed that dont match anything im interested in. @thepracticaldev , dont be afraid to show an empty feed.

anyway...comments.

Code of Conduct, huh... What is it good for?

Kevin Sullivan — Tue, 12 May 2020 13:56:12 +0000

I was reading a post here on dev.to, and one of the replies expressed concern that a certain project resisted adding a CoC directly to the repo. I never really thought about CoC's before, so I wanted to start a discussion and get other people's thoughts.

Here are some questions I'm pondering. Feel free to answer any/all of these, or ask your own.

What are some examples of CoC's that you (dis)like?
What do you think should be included in a CoC?
What have you seen in a CoC before, that you think should not have been included?
What do you perceive are the benefits of including a CoC?
Once a project/repo has a CoC, then what?
Who has personally added a CoC to their repo/project? Why?
Who has personally resisted adding a CoC to their repo/project? Why?
Which successful/popular projects, if any, are not using a CoC?
Which types of projects/repos should have a CoC?
Are there types of projects/repos where you wouldn't add a CoC?
If a project/repo had a CoC, and it were removed, what would be the consequences?
Has any project ever done this?
What does it look like to you to enforce a CoC?
Who does the enforcing?
Has a CoC ever not been enforced?
What did you expect to happen? What actually happened?
Has there been any research on CoC's and their effects on a project/repo?
When you see a project/repo has a CoC, how do you feel about that?
When a project/repo doesn't have a CoC, how do you feel about that?
Do you believe that you have ever personally benefited from a project/repo having a CoC?

[react-native-tests] - run jasmine tests on simulator/emulator/device

Kevin Sullivan — Wed, 08 Apr 2020 23:02:33 +0000

for anyone interested, react-native-tests runs jasmine tests on a simulator/emulator/device

strongly inspired by the test suite created for expo/expo

let me know what you think. useful? improvements?

thanks

React Context: One way to do it

Kevin Sullivan — Fri, 17 Jan 2020 06:27:56 +0000

If you haven't already read Kent C. Dodds' post on React Context, do it now.

I've since tweaked it to my own liking.

import * as React from "react";

import { useTicTacToe } from "./hook";

export const TicTacToeContext = React.createContext<
  ReturnType<typeof useTicTacToe>
>(undefined);

export const TicTacToeProvider: React.FC = ({ children }) => (
  <TicTacToeContext.Provider value={useTicTacToe()}>
    {children}
  </TicTacToeContext.Provider>
);

export const useTicTacToeContext = () =>
  React.useContext(TicTacToeContext) || missingProvider();

const missingProvider = () => {
  throw new Error(
    "useTicTacToeContext must be used inside a TicTacToeProvider"
  );
};

// SELECTORS
export const useBoard = () => useTicTacToeContext().board;
export const useCurrentPlayerId = () => useTicTacToeContext().currentPlayerId;
export const useGameOver = () => useTicTacToeContext().gameOver;
export const useTied = () => useTicTacToeContext().tied;
export const useWinnerId = () => useTicTacToeContext().winnerId;
export const useWinningSquares = () => useTicTacToeContext().winningSquares;
export const useMove = () => useTicTacToeContext().move;
export const useNewGame = () => useTicTacToeContext().newGame;

Keep it stupid simple

For me, the context's sole job is to to provide the return value from a hook, to all its children. So, in this context, the hook is imported, passed into the context....and that's it.

Feel free to not shoot yourself in the foot

The context defaults to undefined. The react docs indicate that you can default to any value.

The defaultValue argument is only used when a component does not have a matching Provider above it in the tree.

Yeah, this might make is easier to test, but when you can render the provider in the test, it's not that much easier. Besides, easy is the enemy of simple. Defaulting to undefined,

export const TicTacToeContext = React.createContext<TicTacToeContextType>(
  undefined
);

combined with

export const useTicTacToeContext = () =>
  React.useContext(TicTacToeContext) || missingProvider();

const missingProvider = () => {
  throw new Error(
    "useTicTacToeContext must be used inside a TicTacToeProvider"
  );
};

prevents you from rendering the consumers outside of a provider. I haven't yet found a good reason to render a consumer without rendering a provider. If you know of any, let me know. Thanks.

Lastly, a few selectors to make reading the hooks a little nicer.

A few other tidbits:

Typescript helper

ReturnType<typeof useTicTacToe> // the type of the return value of the useTicTacToe

Performance

The only time I consider renders is when there is a callback that might be used in a useEffect and mess up the deps array. If the callback is going into a component that doesn't useEffect, like an <input>, then I don't bother with any performance optimizations.

Conclusion

Well, this is one way to do it.

What's your way?

React Router: testing "location.state"

Kevin Sullivan — Thu, 26 Dec 2019 22:01:53 +0000

Background

In the react channel on Spectrum, someone asked how to test that a component displayed data provided by location.state from react-router-dom. I had never done this before, so I sought to find out how to do it.

After some investigation, and trial and error, I came up with the following...

import * as React from "react";
import { render } from "@testing-library/react";
import { Router } from "react-router-dom";
import { createMemoryHistory } from "history";
import { App } from "./App";

it("renders location state", () => {
  const history = createMemoryHistory();
  const state = { a: 123, b: 456 }
  history.push("/", state);

  const { getByText } = render(
    <Router history={history}>
      <App />
    </Router>
  );

  getByText(state.a);
  getByText(state.b);
});

Other Interesting Tidbits

<MemoryRouter history={createMemoryHistory(...)}> doesn't work
<BrowserRouter history={createBrowserHistory(...)}> does work, but doesn't typecheck
According to the docs

Note: Location state is only supported in createBrowserHistory and createMemoryHistory.

and here

location.state - Some extra state for this location that does not reside in the URL (supported in createBrowserHistory and createMemoryHistory)

Conclusion

So, this seems to work. It passes the tests.
Know of a better way? See any problems? Let me know, thanks.

React: Library or Framework? Or something else....

Kevin Sullivan — Sat, 14 Dec 2019 21:03:10 +0000

Have you ever heard someone say this,

React isn't a framework, it's a library

I have.

So, which camp do you fall in? Is it a library? Is it a framework?

Background

I was tasked not too long ago with creating a React Native app (whatever that is...). After developing for a while, I couldn't help but get the feeling that an app framework should do more than React Native was doing. It just didn't feel like a framework. So, maybe I wasn't building a React Native app. Maybe I was building a React app, and using React Native as more of a component library.

After a little while longer, I started getting a similar feeling but for React. The Redux code I was writing seemed more like application stuff, so maybe I was building a Redux app. But then what was I using React for?

...ummm

...errr

...well

I wasn't sure what.

After longer still, I realized Redux was good at encapsulating business logic, but it too didn't feel like an application framework. Maybe I was building a javascript app and using all that other stuff cobbled together to make a framework? Maybe....?

So to better clarify these thoughts, I made an app. It's a simple app. TicTacToe. Here is is, just so you believe me.

Then, I looked at all the places where I used React to see if I could figure out what I was using it for. If it's used for "fundamental stuff" that shapes the app, then it must be a framework, right?

import * as React from 'react'

Let's take a look at one example of using React

// Display.tsx
import * as React from "react";

import { TicTacToeContext } from "../../connect";
import { Col } from "../../../utils";

interface Props {}
interface State {
  display: boolean;
}

export class Display extends React.Component<Props, State> {
  static contextType = TicTacToeContext;
  context: React.ContextType<typeof TicTacToeContext>;

  state = {
    display: true
  };

  render() {
    const { gameOver, currentPlayerId, winnerId, tied, newGame } = this.context;
    const { display } = this.state;

    return (
      <>
        {display ? (
          <button onClick={() => this.setState({ display: false })}>
            Hide
          </button>
        ) : (
          <button onClick={() => this.setState({ display: true })}>Show</button>
        )}
        {display && (
          <Col>
            {!gameOver && `Current Player: ${currentPlayerId}`}
            {gameOver && (
              <>
                {winnerId && `${winnerId} Won!`}
                {tied && "Tied!"}
                <button onClick={newGame}>New Game?</button>
              </>
            )}
          </Col>
        )}
      </>
    );
  }
}

It's a pretty harmless component definition. And it depends on React for a few things. Let's see what we are actually using it for.

React.Component

This component is written using the older (no longer recommended) class syntax. But we could just as easily write this using the "newer" syntax (good old javascript functions). And seeing how classes are kinda like syntactic sugar for functions anyway, let's drop one use of React, and re-write it like this:

export const Display: React.FC = () => {
  const [display, setDisplay] = React.useState(true);
  const {
    gameOver,
    currentPlayerId,
    winnerId,
    tied,
    newGame
  } = React.useContext(TicTacToeContext);

  return (
    <>
      {display ? (
        <button onClick={() => setDisplay(false)}>Hide</button>
      ) : (
        <button onClick={() => setDisplay(true)}>Show</button>
      )}
      {display && (
        <Col>
          {!gameOver && `Current Player: ${currentPlayerId}`}
          {gameOver && (
            <>
              {winnerId && `${winnerId} Won!`}
              {tied && "Tied!"}
              <button onClick={newGame}>New Game?</button>
            </>
          )}
        </Col>
      )}
    </>
  );
};

Types

It looks like we traded one use of React for several more...

export const Display: React.FC = () => { ... }

So, this application is created with typescript, which is then compiled to javascript. React exports some types to help us write typescript. But these types are for the developer, and not for app functionality. We could remove these and the application would still run just fine.

JSX

Even if we were to eliminate every explicit use of React in this component, there would still be one more implicit use: JSX.

Basically, JSX is a syntactic sugar that is meant to be compiled into valid javascript. Well, what does it get de-sugared to?

I'm glad you asked

This:

const element = <h1 className="greeting">Hello, world!</h1>;

Becomes this:

const element = React.createElement(
  "h1",
  { className: "greeting" },
  "Hello, world!"
);

But these function calls get evaluated to (roughly) this:

const element = {
  type: "h1",
  props: {
    className: "greeting",
    children: "Hello, world!"
  }
};

So, React in this capacity, is syntactic sugar and helper functions. We could go so far as to replace all of the JSX in Display.tsx with the objects that they would evaluate to, and eliminate one more use of react.

You can read more about this here

And mess around with a little demo here

Context

I see that this component uses context. That seems kinda significant. So, what's that all about?
React.createContext doesn't do anything all that special. Much like the React.createElement used in JSX, it's a function to help create a plain old javascript object.

From a blog post by Dan Abramov,

// A bit simplified
function createContext(defaultValue) {
  let context = {
    _currentValue: defaultValue,
    Provider: null,
    Consumer: null
  };
  context.Provider = {
    $$typeof: Symbol.for("react.provider"),
    _context: context
  };
  context.Consumer = {
    $$typeof: Symbol.for("react.context"),
    _context: context
  };
  return context;
}

Hooks

So, React provides the Component class (replaced by plain old javascript functions), it provides types (not required to make the app run), it enables JSX which is syntactic sugar for React.createElement which, along with React.createContext, is a helper function to create properly shaped objects.

But it also has that state persistence thing and side effects thing with hooks and all. So for sure it looks like it's creeping into framework territory, right?

const [display, setDisplay] = React.useState(true);

Yeah, about that. React doesn't really do that.

According to Dan Abramov, it's the renderers (react-dom, react-native, and others) that do this, and all of the interesting stuff. Here are a few snippets from his blog post How Does setState Know What to Do?

There is a common misconception that the React “engine” lives inside the react package. This is not true.

In fact, ever since the package split in React 0.14, the react package intentionally only exposes APIs for defining components. Most of the implementation of React lives in the “renderers”.

the base class setState() implementation has been an illusion all along. It doesn’t do anything except forwarding the call to the current renderer. And useState Hook does exactly the same thing.

Okay, so now we know that the react package doesn’t contain anything interesting, and the implementation lives in renderers like react-dom, react-native, and so on.

Case Closed

So React helps developers by providing some niceties, and all the interesting bits are contained in the renderer. So, that seems like case-closed for the library / framework question. But why was this a question to begin with?

I believe the confusion stems from 3 places.

I see value in distinguishing between ReactJS / React and react. I consider react to mean the package, and ReactJS / React to mean the ecosystem. The ecosystem is full of mix-n-match plugins, utilities, helpers, systems, patterns, techniques, and whatever's. With enough of these, you could surely build something that resembles a framework.

Until version 0.14, the react package was all inclusive. It contained all the interesting bits, like state management, context, and the renderer.

And my favorite, calling react a "UI Library". "UI Library" sounds so final to me. Like, "This is the library I use to make UI's". But I've used plenty of libraries to make UI's. Libraries like momentjs. But I would never say I was building a momentjs app. Would you?

Conclusion

In the end, what we call things is a matter of preference, tradition, and expediency. I try to avoid ambiguous terms that have caused confusion, but I'm not dogmatic about it. I won't chew your head off for calling React a framework. Then what's my preference? What do I call it. I think the official website has my favorite description.

React

A JavaScript library for building user interfaces

React Context: (CRUD / REST)-ful Entities

Kevin Sullivan — Tue, 22 Oct 2019 02:36:39 +0000

TLDR;

Here's a link to a codesandbox that uses react context to create a (CRUD / REST)-like interface to local entities. (think: index, new, show, edit, update, destroy)
https://codesandbox.io/s/posts-context-8y1ub?fontsize=14&module=%2Fsrc%2FApp.tsx

Background

Recently, I've been in a codesandbox.io template kick, making starter templates for various purposes. I've got one for generic react, one for react with react-router. And now, I've got one for a react context.

Meat n' Potatoes

In this template, the context provides a restful-ish interface for a Posts entity.

The context provides a state like this:

interface State {
  posts: { [id: string]: Post };
  ids: Post["id"][];
}

...

const ids = usePostIds(); // index-ish
const posts = usePosts(); // index
const post = usePost(123) // show / edit

And behavior like this:

const newPost = useNewPost()          // create
const updatePost = useUpdatePost(123) // update
const deletePost = useDeletePost(123) // destroy

...

<button onClick={() => newPost({ id: 123, title: "first post" })}>Create</button>
<button onClick={() => updatePost({ ...post, title: "updated: })}>Update</button>
<button onClick={() => deletePost()}>Delete</button>

Thoughts...

Well, I haven't put it into anything significant yet, but it seeeeeeems like it makes it simple to add a new entity to keep track of, if you want to treat it in a similar way.

I was able to encapsulate some basic async stuff in the components, and keep all the local state management synchronous.

const savePostToRemoteServer = (post: Post) => {
    setPending(true);
    return wait(1000)
      .then(() => {
        if (!isMounted()) return
        newPost(post);
      })
      .finally(() => {
        if (!isMounted()) return
        setPending(false);
        setTitle("");
      });
  };

I haven't done any error handling, so who know how that would go. Probably keep it all in the components alongside the async stuff.

It's not super faithful to either CRUD or REST and the naming convention is mixed, so...who knows.

Anyway....

Here's the link to the codesandbox if you want to dive more into it.

https://codesandbox.io/s/posts-context-8y1ub?fontsize=14&module=%2Fsrc%2FApp.tsx

Feedback

Let me know what you all think. Your feedback is very valuable.
Thanks.

React Router: Simplifying a user flow

Kevin Sullivan — Tue, 15 Oct 2019 04:36:18 +0000

TLDR;

I used react-router and nested routers to clean up a particular user flow

Background

Recently, I've been developing a React Native / Expo application for a client that involves a user flow akin to a registration signup. (~10 screens, in a specific order, with a form)

I've been using react-router, (in this case react-router-native), like this...

// App.tsx
...
<Router>  
// ...some other routes


// routes pertaining to a single "entity"
  <Route path={"/path/to/route/a"}>
    <ScreenA />
  </Route>

  <Route path={"/path/to/route/b"}>
    <ScreenB />
  </Route>

  <Route path={"/path/to/route/c"}>
    <ScreenC />
  </Route>
</Router>
...

Unfortunately, when using react-router this way, every screen in the user flow that links to another route must know the path of that route.

// ScreenB.tsx
...
<Link to={"/path/to/route/a"}>Back</Link>
<Link to={"/path/to/route/c"}>Next</Link>
...

My attempts to address this include:

Pass the next path in as a prop

<Route path={"/path/to/route/b"}>
  <ScreenB nextPath={"/path/to/route/c"} />
</Route>

Pass the <Link /> in as a prop

<Route path={"/path/to/route/b"}>
  <ScreenB nextButton={<Link path={"/path/to/route/c"} />} />
</Route>

Pull the <Link /> out into a peer component

<Route path={"/path/to/route/b"}>
  <>
    <ScreenB />
    <NavFooter nextPath={"/path/to/route/c"} />
  </>
</Route>

Pros

They all move the knowledge of the order into a single place.
2 and 3 remove the dependency on <Router />

Cons

Kinda ugly
Still have to "manage" the knowledge

My Solution

When messing around one day, I decided to make the app as modular as possible, you know, just for the hell of it. I started by making each "entity" its own "sub-app". This meant putting all the files for a given entity in a separate folder, essentially mirroring the "root-app". I migrated the sub-app closer and closer to the format of the root-app until I came to the part that made me hesitate.... <Router>. Hmmm, I thought. Could it work? Could I put a <Router> inside another <Router>.........?

Yep. So I did. And some neat stuff fell out.

So, apparently <NativeRouter> and <BrowserRouter> inherit from <MemoryRouter>. And <MemoryRouter> has an interesting prop, initialEntries. This is used to seed the router in your tests with history. Well, if <MemoryRouter> has it, then so does everything else.

By using this prop, I can inject into <Router>, all the routes, in the correct order, giving me a router that looks like

const ENTRIES = ["/a", "/b", "/c"] // <- makes it easy to add, remove, change order
<Router initialEntries={ENTRIES}>
  <Route path={"/a"}>
    <ScreenA />
  </Route>

  <Route path={"/b"}>
    <ScreenB />
  </Route>

  <Route path={"/c"}>
    <ScreenC />
  </Route>
</Router>

and screens that have buttons like

// ScreenB.tsx
...
<Link onPress={history.goBack}>Back</Link>
// I turned this into <BackButton /> */
<Link onPress={history.goForward}>Next</Link>
// I turned this into <NextButton />
...

Conclusion

Modularity for the win
Not all who wander are lost
Probably some other stuff

React Hook: useSideMenu()

Kevin Sullivan — Sat, 05 Oct 2019 02:56:12 +0000

TLDR;

Here is a snack similar to how I'm implementing a side menu in a React Native / Expo app
https://snack.expo.io/@wolverineks/withsidemenu

Background

I'm currently building a React Native / Expo app for a client. The app uses React Router, and React Native Drawer.

Some of the routes have a side menu, and some do not. So I wrote context like...

interface SideMenuContext {
  open: () => void;
  close: () => void;
  enable: () => void;
  disable: () => void;
  enabled: boolean;
  shouldOpen: boolean;
}

and a hook like...

export const useSideMenu = () => {
  const sideMenu = React.useContext(SideMenuContext);
  if (sideMenu === undefined) {
    throw new Error("useSideMenu must used in a SideMenuProvider");
  };
  const { enable, disable, close } = sideMenu

  React.useEffect(() => {
    enable();

    return () => {
      disable();
      close();
    };
  }, []);

  return sideMenu;
};

and on the screens that have a side menu:

const SomeScreen = () => {
  useSideMenu()

  return ...yada...yada...yada
}

Can anyone spot the undesirable behavior?

So, I noticed a few things about this approach that I didn't like.

The imperative nature of the hook api meant that if (for some reason) multiple components that useSideMenu are mounted simultaneously, removing any of them would disable the side menu. The behavior I was looking for was, disabling the side menu only if all of the components were unmounted.
When testing the screens in isolation, a <SideMenuProvider /> would have to be mounted, or the hook would throw an error.

Next Steps

To overcome the second issue, I've written a component, <WithSideMenu />, and moved the useSideMenu() call from just inside the screens, to just outside of the screens...

<WithSideMenu> 
  <SomeComponent />
</WithSideMenu>

And, to overcome the first issue, I've rewritten the context to...

interface SideMenuContext {
  open: () => void;
  close: () => void;
  register: () => () => void; // <- returns an "unregister"
  enabled: boolean;
  shouldOpen: boolean;
<Drawer />
}

to be used like...

const WithSideMenu: React.FC = ({ children ) => {
  const sideMenu = useSideMenu()
  const { register } = sideMenu;

  React.useEffect(register, []);

  return typeof children === "function"
    ? children(sideMenu)
    : children;
};

Conclusion

Declarative for the win.
Composition for the win.
Probably some other stuff...

Here is the snack again:

https://snack.expo.io/@wolverineks/withsidemenu

Initializing array with length

Kevin Sullivan — Sat, 21 Sep 2019 15:22:21 +0000

Straight to the point....

> Array.from({ length: 5 })
[ undefined, undefined, undefined, undefined, undefined ]

What?!?

Yah....I know, right....

An example of improving readability in a React component

Kevin Sullivan — Tue, 10 Sep 2019 18:05:19 +0000

Recently, someone asked for a second set of eyes on a component they had written. They indicated that they wanted a better way to write it, but didn't specify what they thought could use improvement.

In cases like these, I like to chant the mantra

Make it work
Make it pretty
Make it fast

In this case, the code works. So, on to step 2. (I rarely ever go on to step 3)

Here is the original code.

// yada yada yada, imports...

interface StatusBarProps {
  accent: string;
}

const MyStatusBar = ({ accent }: StatusBarProps) => {
  switch (accent) {
    case "yellow":
      if (Platform.OS === "ios") {
        return (
          <View
            style={{
              width: "100%",
              height: getStatusBarHeight(),
              backgroundColor: COLORS.yellow,
            }}
          >
            <StatusBar
              translucent={false}
              barStyle="light-content"
              backgroundColor={COLORS.yellow}
            />
          </View>
        );
      } else {
        return (
          <StatusBar
            translucent={false}
            barStyle="light-content"
            backgroundColor={COLORS.yellow}
          />
        );
      }
    case "purple":
      if (Platform.OS === "ios") {
        return (
          <View
            style={{
              width: "100%",
              height: getStatusBarHeight(),
              backgroundColor: COLORS.purple,
            }}
          >
            <StatusBar
              translucent={false}
              barStyle="light-content"
              backgroundColor={COLORS.purple}
            />
          </View>
        );
      } else {
        return (
          <StatusBar
            translucent={false}
            barStyle="light-content"
            backgroundColor={COLORS.purple}
          />
        );
      }
    default:
      return (
        <StatusBar
          translucent={false}
          barStyle="light-content"
          backgroundColor={COLORS.white}
        />
      );
  }
};

What does it do?

My first observation is this component does not scream what is does. A real 10x developer reads 10x more code than they write. So anything you can do to reduce the time it takes for someone to read your code will pay dividends.

It appears that this component does 2 things:

Add a <View> wrapper on ios and not on android
Set the background color based on a prop

Well, unix philosophy, roughly speaking, says

Do one thing, and do it well.

So, let's break this into to parts.

Platform Specific Imports

In the React Native docs you can find a section on Platform Specific Imports

This means that when using import { MyStatusBar } from "./MyStatusBar, react-native will automatically import the component from MyStatusBar.android.tsx on android and MyStatusBar.ios.tsx on ios. With this we can remove the platform-based logic from the component.

if (Platform.OS === "ios") {
  ...yada yada ios stuff
} else {
  ...yada yada android stuff
}

What does a `switch` statement do?

In the switch statement, the cases seem pretty similar. This makes it difficult to know what the switch statement is doing. To determine what a specific switch statement is doing, look at what the differences are between the cases. In this instance, the only difference in the cases are the value passed to backgroundColor. So, if we limit this switch statement to only determining that value, we can reduce the component to:

// MyStatusBar.android.tsx
// ...stuff

let backgroundColor = COLORS.white
switch (accent) {
  case "yellow": backgroundColor = COLORS.yellow
  case "purple": backgroundColor = COLORS.purple
}

return <StatusBar translucent={false}
  barStyle="light-content"
  backgroundColor={backgroundColor} />

or better still

// MyStatusBar.android.tsx
// ...stuff

const DEFAULT_BACKGROUND_COLOR = COLORS.white

// ...more stuff

return <StatusBar translucent={false}
  barStyle="light-content"
  backgroundColor={COLORS[accent] || DEFAULT_BACKGROUND_COLOR} />

Conclusion

When writing a component, or any code for that matter, I ask myself some questions about some future developer that is reading this code for the first time, or the first time in a while...

How long will it take them to know what this code does?
Are there any parts of the code that take them longer to understand than others?
Will they need to know what each part of this code does, or can some of it abstracted away?
Are they aware of alternatives that are more standardized/recognizable than any of the patterns used here?
Are they confused about the naming of any variables?
Are they confused about the number of parameters, or their types?
Which parts of this code would they need to change in order to implement some possible changes in the future?
When implementing changes, which part of this code is more likely going to be a foot-gun?

So yeah, that's it on that topic.

I'd be interested in any examples you have of refactoring React components to increase readability, so please put them in the comments.

Thanks.

Untangle react contexts that depend on each other?

Kevin Sullivan — Sun, 18 Aug 2019 08:06:50 +0000

Recently on Twitter a question was asked, roughly, how to untangle 2 react contexts that use state/callbacks provided by each other.

Several answers were suggested, ranging from combining them into a single context, to using callbacks from one context to sync state with another.

While I have no doubt that any of the provided solutions could be made to work, I couldn't help but think about another solution that I think is more in the react style of composition.

So, without further ado, my solution:

Much like the unix philosophy of "Do 1 thing, and do it well", each context is reduced to a single responsibility. The two original contexts can now be used independently, with the third context doing only the composition.

Feel free to provide feedback. Good? Bad? Pro's / Con's?

DEV Community: Kevin Sullivan

what are the missing features on dev.to?

Code of Conduct, huh... What is it good for?

[react-native-tests] - run jasmine tests on simulator/emulator/device

React Context: One way to do it

Keep it stupid simple

Feel free to not shoot yourself in the foot

A few other tidbits:

Typescript helper

Performance

Conclusion

React Router: testing "location.state"

Background

Other Interesting Tidbits

Conclusion

React: Library or Framework? Or something else....

Background

import * as React from 'react'

React.Component

Types

JSX

Context

Hooks

Case Closed

Conclusion

React Context: (CRUD / REST)-ful Entities

TLDR;

Background

Meat n' Potatoes

Thoughts...

Anyway....

Feedback

React Router: Simplifying a user flow

TLDR;

Background

Pros

Cons

My Solution

Conclusion

React Hook: useSideMenu()

TLDR;

Background

Can anyone spot the undesirable behavior?

Next Steps

Conclusion

Initializing array with length

An example of improving readability in a React component

What does it do?

Platform Specific Imports

What does a switch statement do?

Conclusion

Untangle react contexts that depend on each other?

What does a `switch` statement do?