DEV Community: c0d3t3k

Blitz.js + React Three Fiber == React Three Blitz?!

c0d3t3k — Wed, 24 Feb 2021 17:36:22 +0000

Blitz.js + React Three Fiber ==> React Three Blitz?

In order to celebrate the recent Blitz.js promotion to formal Beta,

// Detect dark theme var iframe = document.getElementById('tweet-1362048912476016642-823'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1362048912476016642&theme=dark" }

we thought it might be fun to see how it integrates with one of our favorite frameworks, React Three Fiber. Introducing react-three-blitz!

What is Blitz.js?

If you haven't seen it yet, you owe it to yourself to checkout one of Brandon Bayer's (the founder and chief evangelist of Blitz.js) very thorough video introductions.

We are intrigued by blitz.js because it offers a compelling, uniquely integrated (Rails-like?) monolithic, full stack solution built using top tier open source components (React, Next.js, Prisma ORM, React Query, Passport.js Auth Strategies,etc.).

What is react-three-fiber?

To put it simply, r3f a React renderer for THREE.js for the web and react-native. THREE.js has been a gamechanger but we really feel that @0xca0a/@drcmda et al's react-three-fiber [and the Drei utilites!] takes it to the next level by wrapping THREE.js primitives, etc. to keep all of our 3D web dev concise and performant.

A lot of credit for this integration idea goes to @onireanud et al and his @pmndrs umbrella creation react-three-next. This excellent project introduces a compelling pattern, especially for integrating r3f and next.js.

Specifically, react-three-next uses a unified layout model containing a THREE.js/r3f canvas and a react DOM container overlaid on top of each other. A rendering filter is used to seperate HTML and r3f components and render them in the appropriate container.

Below is a quick rundown of changes we added/changed to get our 3D adventure started:

Fix/Circumvent SSR using next-transpile-modules

Three.js, Drei etc. don't play well with SSR so we needed a way to pre-transpile these libraries.

Reusable Canvas

Our goal here was to leverage a "reusable" Canvas ala react-three-next. All "3D" elements (hero, logo, etc. in our case) would render as children of this element. We also included some configurable niceties like r3f-perf, OrbitControls.

DOM/HTML Component Container

Also similarly to react-three-next we used a wrapper for all non 3D or plain "dom" elements.

SplitApp

Then, we use this component either aggregate the 3D and non-3D components, if 3D components are present. Or, just output a standard non-canvas component wrapper.k

Layout

As described earlier, this component is used to create separate arrays of r3f and HTML based on the presence of a "key". Using these arrays we determine whether or not to display the Canvas.

Index

Finally, we import our 3D component and disable SSR. Then, we use the Layout component from above and mark each 3D with a key (i.e. 'r3f', etc.) to let the render know we will be presenting a r3f component.

The react-three-blitz starter is definitely a work-in-progress. In fact, we don't have all the coolness ported yet from react-three-next (i.e. transitions, webpack customization, etc.). Also, there in-progress r3f issue preventing us from sharing a canvas across routes to optimize navigation responsiveness.

Allow opting out of forceContextLoss() #1004

robonyong posted on Feb 11, 2021

I'm working on a page where I would like to reuse/manage webgl contexts outside of the specific components that use Canvas. would it be possible to add a way to opt out of Canvas calling forceContextLoss() on unmount?

View on GitHub

Nevertheless, we encourage you to give react-three-blitz a spin!

-c0d3t3k

c0d3t3k / react-three-blitz

React Three Fiber experimental starter template powered by Blitz.js

react-three-blitz

Blitz.js experiment/starter influenced heavily by @onireanud et al react-three-next

Getting Started

Run your app in the development mode.

yarn
yarn dev

Open http://localhost:3000 with your browser to see the result.

Interesting Changes

List of delta's from the base Blitz.js generated app

react-three-blitz
├── app/
│   ├── core/
|   │   └── components/ 
│   │   |   └── DarkMode.tsx
│   │   |   └── Logo.tsx
│   │   └── layouts/
│   │       └── _canvas.tsx
│   │       └── _dom.tsx
│   │       └── Layout.tsx
│   ├── pages/
│   │   ├── _app.tsx
│   │   └── index.tsx
│   │   └── hero.tsx
│   ├── api/
│   ├── auth/
│       ├── pages/
│       ├── login3d.tsx
│       └── signup3d.tsx
├── blitz.config.js
├── tsconfig.json

#shouldersofgiants shoutouts:

View on GitHub

Jotai, now with Optics

c0d3t3k — Sat, 31 Oct 2020 14:05:48 +0000

More and more functional paradigms have been finding their way into our contracting work. This really accelerated when we started using React Hooks a while back. In fact, back in the day, we were tasked to convert a legacy Angular ThreeJS project we had written earlier to React / react-three-fiber for performance, ease of maintenance, etc. Given the increasing complexity, we wanted a more atomic, composable state management system (of course this was before Recoil had been introduced). After some due diligence, we settled on Grammarly's Focal. This library, although a bit older, is powerful and introduced us to the intriguing FP concepts of Optics, Lenses, etc

Fast forward to now and we are learning more about Jotai, a Recoil alternative from Poimandres ( creators of react-three-fiber, etc.). Needless to say, we were very excited when we stumbled upon Jotai Issue #44, a discussion concerning focusable atoms started by Meris Bahtijaragic and the compelling work that resulted, jotai-optics. This code wraps another library we have been very intrigued by as of late, optics-ts which provides a whole new level of typesafe, functional goodness.

Now, if the concept of Optics is new to you, there are some excellent introductions in the context of functional programming. One such concise example is @gcanti's article on lenses and prisms, and there are plenty more. John DeGoes' Glossary of Functional Programming will also help with any new FP vocabulary. However, our humble goal here is to provide more of a practical (vs academic) example.

In order to explore this new functionality, we will use an existing Recoil example. We will not only convert to Jotai, but also add some extra functionality to soft introduce some benefits of jotai-optics (and optics-ts).

For this exercise, we thought it might be fun to upgrade Diogo Gancalves' cool Joeflix app to JotaiFlix!

Let's get started.

First, we we need to replace RecoilRoot with the Jotai Provider

// App.js exceprt
...
//import {RecoilRoot} from 'recoil'
import { Provider } from "jotai";

...

function App() {
  return (
    /* <RecoilRoot> */
    <Provider>
    <JotaiDebugger />
      <Router>
        <FeedbackPopup />
...

Next, we will add some Favorites and History to the UI. This will give us some specific user generated state our Optics can act upon. In order to accomplish this, we need to first create some Jotai Atoms that will store this state. While we are at it, we will include some default values.

// state.js excerpt
...
export const historyAtom = atom([
    {id: 62286, title: "Fear the Walking Dead", desc: "What did the world look like as it was transformin… the end of the world, will answer that question.", banner: "/58PON1OrnBiX6CqEHgeWKVwrCn6.jpg", type: "tv"},
    {id: 528085, title: "2067", desc: undefined, banner: "/5UkzNSOK561c2QRy2Zr4AkADzLT.jpg", type: "movie"}
])

export const favoritesAtom = atom([
    {id: 590223, title: "Love and Monsters", desc: undefined, banner: "/lA5fOBqTOQBQ1s9lEYYPmNXoYLi.jpg", type: "movie"},
    {id: 76479, title: "The Boys", desc: "A group of vigilantes known informally as “The Boys” set out to take down corrupt superheroes with no more than blue-collar grit and a willingness to fight dirty.", banner: "/mGVrXeIjyecj6TKmwPVpHlscEmw.jpg", type: "tv"}
])
...

Now we need a function that determines if a given movie/show is already contained in either the Favorites or History collection. If it is present, it removes it, if not present it adds it.

Lets talk about what is happening here. In short, we use a jotai-optics wrapped optics-ts isomorphism to transform the internally passed atom collection passed by the outer focus call.

Because we need to track both the current and converted boolean value, we create a wrapper object within the optic that has two properties (contained and value). The contained property tracks the boolean output of the optic and the value property tracks the array that potentially contains the specified item.

// optics.js
export const containsOptic = (item) => {

    return O.optic()
        .iso(
            // Lens that is isomorphically converting an array given an item 
            // to a boolean determining whether the array contains that item.
            (val) => ({ 
                contained: (item && item.id) ? (_.findIndex(val, (currentItem) => item.id == currentItem.id) > -1) : false,
                value: val
            }),
            (obj) => {
                if(!(item && item.id)) {
                    return collection;
                }

                const collection = _.clone(obj.value);

                const index = _.findIndex(collection, (currentItem) => item.id == currentItem.id);

                if(obj.contained && index < 0) {
                    collection.push(item);
                } else if(!obj.contained && index > -1) {
                    collection.splice(index, 1);
                }

                return collection;
            }
        )
        .prop('contained');

To keep things relatively simple in the BigTile.js, Tile.js and Hero.js files we call our containsOptic factory function above to instantiate an optic that will provide not only History and Favorite state, but a way to easily set it.

// Tile.js excerpt

...
function Tile({data}) {

    // https://github.com/merisbahti/jotai-optics
    const [isInHistory, setIsInHistory] = 
        useAtom(focus(historyAtom, optic => optic.compose(containsOptic(data))))
    const [isFavorite, setIsFavorite] = 
        useAtom(focus(favoritesAtom, optic => optic.compose(containsOptic(data))))

Finally, we'll add some icon buttons to call the respective setters created by the jotai-optics focus method above, to mutate the Favorites and History state.

// Continued Tile.js excerpt

    const toggleFavorites = () => {
        setIsFavorite(!isFavorite);
    }
    const playMedia = () => {
        setIsInHistory(!isInHistory);
    }

    ...
    <button className="tile__play"  onClick={() => toggleFavorites()}>
        {isFavorite ? <AiFillHeart /> : <AiOutlineHeart />}
    </button>
    ...
    <button className="tile__play" onClick={playMedia}>
        <img className="tile__icon" src={require('../images/streamline-icon-controls-play@15x15.png')} alt=""/>
    </button>
...

And that about does it!

Final Thoughts:

Using an optics based implementation ensures that state mutations can be modular and concise.
With the @akeron's optics-ts library, powerful optics can be constructed, leading to easily repeatable patterns and clean architecture
@merisbahti's jotai-optics provides a straightforward integration between Jotai and optics-ts.
Obviously, this was a very simple integration, but we feel it cracks open the door for some powerful functional programming integrations between Jotai and jotai-optics especially in light of the impressive feature set of optics-ts

Codesandbox example is included below.

NOTE: This sample code includes Jotai Dev Tools so be sure to use a Redux DevTools Browser Extension to easily observe the relevant state changes. For more info, please see our previous article.

Jotai (not exactly Redux) Dev Tools

c0d3t3k — Wed, 28 Oct 2020 22:22:42 +0000

Recently, we have begun investigating Jotai, a state management alternative to Recoil by Poimandres. In addition, we documented some light investigation converting an existing Recoil app to Jotai in a previous article. While performing this exercise it got us thinking about what debug tools that might be available which are specifically targeted to Jotai. Unfortunately, as of this writing all that is available is the useDebugValue hook.

Now, like most folks, we enjoy using powerful and versatile dev tools such as React DevTools, React Query DevTools, etc. While we have not used Redux in a production capacity in the past, (for a number of reasons) we have always preferred to use ReduxDevTools for debugging React state management systems. In fact, we have created these custom internal plugins for each state management system we have used in our contracting work. As of this writing, we couldn't find a Jotai plugin yet, so naturally we thought it might be interersting to attempt to create one.

First, we setup some interfaces/types for Config, Message, ConnectionResult, Extension, etc. to match the payloads transmitted from/to ReduxDevTools. These interfaces enable strongly typed mapping for communication with the Browser Extension proper.

interface Config {
    instanceID?: number,
    name?: string,
    serialize?: boolean,
    actionCreators?: any,
    latency?: number,
    predicate?: any,
    autoPause?: boolean
}

interface Message {
    type: string,
    payload?: any,
    state?: any
}

interface IConnectionResult {
    subscribe: (dispatch: any) => {};
    unsubscribe: () => {};
    send: (action: string, state: any) => {};
    error: (payload: any) => {};
}

type ConnectionResult = IConnectionResult & Observable<Message>

interface Extension {
    connect: (options?: Config) => ConnectionResult;
}

Unfortunately, the Redux DevTools connect function used for the browser extension frontend does not return a standard RxJS Observable. Consequently, we need the wrapConnectionResult function to make a RxJS compatible observable to receive ReduxDevTools events.

const wrapConnectionResult = (result: ConnectionResult) => {
    const subject = new Subject<Message>()

    result.subscribe(
        (x: any) => subject.next(x),
        (x: any) => subject.error(x),
        () => {subject.complete()}
    );

    return subject;
}

Now we'll implement a JotaiDevtoolsProps interface so that the user can name and configure DevTools instances.

interface JotaiDevtoolsProps {
    atom: WritableAtom<any, any>,
    name?: string,
    config?: Config
}

To enable seamless integration with React Functional Components, we create a hook that will take our JotaiDevtoolsProps and instantiate an instance for a particular Jotai atom.

...
export const useJotaiDevtools = ({ atom, name, config, ...props }: JotaiDevtoolsProps) => {
...

Next, we'll use the observable-hooks library's useObservable hook to provide the value of the incoming atom as an RxJS observable.

    const atom$ = useObservable((input$) => input$.pipe(
        map(([x]) => x)
    ), [atomCurrentValue]);

In order to prevent a race condition when an atom is updated, we'll add a flag to determine whether the last state update was a ReduxDevTools Time Travel Event.

    const [wasTriggeredByDevtools, setWasTriggeredByDevtools] = useState(() => false);

Additionally, we need a flag to determine if the initial state has already been sent to the DevTools Extension.

    const [sentInitialState, setSentInitialState] = useState(() => false);

    const [devTools, setDevTools] = useState<ConnectionResult>();

Since the DevTools connection may not be availiable when the hook is initialized, we will add another useObservable to provide a sanitized stream of events when the connection is ready.

    const devTools$ = useObservable((input$) => input$.pipe(
        filter(([x]) => !!x),
        switchMap(([x]) => wrapConnectionResult(x as ConnectionResult)),
        catchError((error, observable) => {
            console.error(error);
            return observable;
        })
    ), [devTools]);

This function is called to handle State Jumps and Time Travel events.

    const jumpToState = (newState: any) => {
        setWasTriggeredByDevtools(true)
        // var oldState = atomCurrentValue();
        setAtom(newState);
        // setWasTriggeredByDevtools(false);
    };

Continuing our previous pattern, we will use observable-hook's useSubscription hook to subscribe to the DevTools Extension events and respond appropriately to either either a START or DISPATCH action.

    useSubscription(devTools$, (message) => {
        switch (message.type) {
            case 'START':
                console.log("Atom Devtools Start", options.name, atomCurrentValue)
                if(!sentInitialState) {
                    // devTools.send("\"" + options.name + "\" - Initial State", atom.getState());
                    devTools?.send(name + " - Initial State", atomCurrentValue);
                    setSentInitialState(true);
                }
                return;
            case 'DISPATCH':
                if (!message.state) {
                    return;
                }
                switch (message.payload.type) {
                    case 'JUMP_TO_ACTION':
                    case 'JUMP_TO_STATE':
                        jumpToState(JSON.parse(message.state));
                        return;
                }
                return;
        }
    });

Next, we will need another useSubscribe hook to subscribe updates coming from application state changes to the current Jotai atom.

    useSubscription(atom$, (state) => {
        if (wasTriggeredByDevtools) {
            setWasTriggeredByDevtools(false);
            return;
        }
        devTools?.send(name + " - " + moment().toISOString(), state);
    })

When the component is initialized, we will need a function to get a reference to the DevTools Extension. If the extension is not installed, an error will be logged to the console.

    const initDevtools = () => {
        const devtools = (window as any).__REDUX_DEVTOOLS_EXTENSION__ as Extension;
        // const options = config;
        const name = options.name || window.document.title;

        if (!devtools) {
            console.error('Jotai Devtools plugin: Cannot find Redux Devtools browser extension. Is it installed?');
            return atom;
        }

        const devTools = devtools.connect(options);

        console.log("Get Dev Tools", devTools, of(devTools));

        setDevTools(devTools);

        // setTimeout(() => devTools.send(name + " - Initial State", atomCurrentValue), 50)

        return atom;
    }

In order to activate our initialization function, we will utilize the useLifeCycles hook (from the excellent react-use library) to handle the component mount lifecycle event.

    useLifecycles(() => {
        initDevtools();
    });

That's it. Now just install the new Jotai Devtools plugin in any projects that utilize Jotai atoms.

Specifically, we can just call the useJotaiDevtools hook for each atom you want to view in the Devtool Browser Extension

...
    useJotaiDevtools({
        name: "Dark Mode",
        atom: darkModeState
    });
...

    useJotaiDevtools({
        name: "Tasks",
        atom: tasksAtom
    });

...

For illustration, we can re-use the Recoil example we converted to Jotai in a previous post. Once the app is started, we can open the Redux DevTools Browser Extension and we will be able to watch our state changes, time travel debug, etc.

Final Thoughts:

By leveraging the existing work done on ReduxDevTools, we have access to a useful debugging aid without reinventing the wheel.
Leveraging the observable-hooks and react-use libraries enabled clean and efficient ReduxDevTools integration.
Adapting the time travel functionality of ReduxDevTools enables full replay of the Jotai chain of state.
The result is a compelling insight into the Jotai atom lifecycle.
Check out the Jotai Devtools Repo on Github!

Below is a functioning example. If you haven't already, make sure you install the Redux DevTools extension to be able to see the state update.

Recoil to Jotai (with Typescript)

c0d3t3k — Wed, 28 Oct 2020 16:42:17 +0000

Our consulting team has enjoyed using several excellent react libraries such as react-spring, react-three-fiber, react-three-flex lately. As a result, we were intrigued when Poimandres' announced Jotai, a Recoil state management alternative. Couple this with the fact we have been using more and more TypeScript, we thought it might be interesting to explore the differences between a Recoil project and one implemented in Jotai with respect to explicit typing.

In an attempt to approximate an 'apples to apples' comparison, we decided on Jaques Bloms' recoil-todo-list as a starting point. It not only uses Typescript, but also utilizes a number of Recoil idioms like Atoms, Selectors and AtomFamily

Below are some highlights of the recoil-todo-list conversion. These steps attempt to illustrate some of the syntatic/algorithmic differences between the two libraries. So let's dive in!

Similar to Recoil, Jotai uses a context provider to enable app wide access to state. After installing Jotai just needed to modify the index.tsx from Recoil's <RecoilRoot> to Jotai's <Provider>.

// index.tsx

import React from 'react'
import ReactDOM from 'react-dom'
import App from './App'
import { Provider } from 'jotai'
//import {RecoilRoot} from 'recoil'

ReactDOM.render(
    <React.StrictMode>
        {/* <RecoilRoot> */}
        <Provider>
            <App />
        </Provider>
        {/* </RecoilRoot> */}
    </React.StrictMode>,
    document.getElementById('root'),
)

The snippet below implements the app's obligatory Dark Mode state management. In Header.tsx just need a small syntatic change to Jotai's {atom, useAtom} from Recoil's {atom, useRecoilState}.

// Header.tsx except
...

export const Header: React.FC = () => {
    // RECOIL //
    //const [darkMode, setDarkMode] = useRecoilState(darkModeState)

    // JOTAI //
    const [darkMode, setDarkMode] = useAtom(darkModeState)

...

Next, we needed to convert Tasks.tsx. We chose to go with an Task interface in order to custom defined type a TasksAtom that will be used to store the Task indexes.

// Tasks.tsx excerpt

...
// RECOIL //
// export const tasksState = atom<number[]>({
//     key: 'tasks',
//     default: [],
// })

// export const tasksState = atom([] as number[])

// JOTAI //
export interface Task {
    label: string,
    complete: boolean
}

export const tasksAtom = atom<number[]>([])

export const Tasks: React.FC = () => {
    const [tasks] = useAtom(tasksAtom)
...

Then we converted Task.tsx, using a Jotai util implementation similar to Recoil's atomFamily. Notice here that Jotai's implementation of atomFamily includes an explicit definition of a getter and setter which internally utilizes the tasksAtom defined in Tasks.tsx.

Btw, Jotai Pull Request #45 went a long way in helping us understand how this should work (props to @dai-shi and @brookslybrand)

// Task.tsx excerpt
...

// RECOIL //
// export const taskState = atomFamily({
//     key: 'task',
//     default: {
//         label: '',
//         complete: false,
//     },
// })

// JOTAI //
// https://github.com/pmndrs/jotai/pull/45
export const taskState = atomFamily(
    (id: number) => ({
        label: '',
        complete: false,
    } as ITask)
)


export const Task: React.FC<{id: number}> = ({id}) => {
    //const [{complete, label}, setTask] = useRecoilState(taskState(id))
    const [{complete, label}, setTask] = useAtom(taskState(id))
...

The next file to convert is Input.tsx. We chose to substitute the Recoil useRecoilCallback with Jotai's useAtomCallback.

// Input.tsx excerpt

...
    // RECOIL
    // const insertTask = useRecoilCallback(({set}) => {
        //     return (label: string) => {
        //         const newTaskId = tasks.length
        //         set(tasksState, [...tasks, newTaskId])
        //         set(taskState(newTaskId), {
        //             label: label,
        //             complete: false,
        //         })
        //     }
        // })

    // JOTAI //
    const insertTask = useAtomCallback(useCallback((
        get, set, label: string
    ) => {
        const newTaskId = tasks.length
        set(tasksAtom, [...tasks, newTaskId])
        set(taskState(newTaskId), {
            label: label,
            complete: false,
        })
    }, [tasks]));
...

Finally, in Stats.tsx, we replaced the Recoil Selectors with readonly Jotai Atoms using computed Task state. In this case, there appears to be only a slight syntatic difference, mostly around the use of string reference keys.

// Stats.tsx excerpt
...

// RECOIL //
/*
const tasksCompleteState = selector({
    key: 'tasksComplete',
    get: ({get}) => {
        const taskIds = get(tasksState)
        const tasks = taskIds.map((id) => {
            return get(taskState(id))
        })
        return tasks.filter((task) => task.complete).length
    },
})

const tasksRemainingState = selector({
    key: 'tasksRemaining',
    get: ({get}) => {
        const taskIds = get(tasksState)
        const tasks = taskIds.map((id) => {
            return get(taskState(id))
        })
        return tasks.filter((task) => !task.complete).length
    },
})
*/

// JOTAI
const tasksCompleteState = atom(
    get => {
        const tasksState = get(tasksAtom)
        const tasks = tasksState.map((val, id) => {
            return get(taskState(id))
        })
        return tasks.filter((task: Task) => task.complete).length
    },

)
const tasksRemainingState = atom(
    get => {
        const tasksState = get(tasksAtom)
        const tasks = tasksState.map((val, id) => {
            return get(taskState(id))
        })
        return tasks.filter((task: Task) => !task.complete).length
    }
  )
...

Final Thoughts:

Overall, we were impressed by how things "just worked".
The syntactic differences were easy to navigate as well as the different mechanisms for referencing atoms.
With the relative lack of documentation currently available, we recommend reviewing Jotai issues and pull requests to get more familiar with the concepts and techniques.
We enjoyed this exercise and as a result will be doing more investigation into using Jotai in our production solutions.

Github Source and CodeSandbox are also available.