useObservables for react hooks

[ericvicenti]

Hey all, I've found withObservables to be super handy, but now with react hooks I've been using a simple "useObservables" instead:

import { useState, useEffect } from 'react';

export default function useObservable(observable) {
  const [value, setValue] = useState(observable && observable.value);

  useEffect(
    () => {
      if (!observable || !observable.subscribe) {
        return;
      }
      const subscription = observable.subscribe(setValue);
      return () => subscription.unsubscribe();
    },
    [observable]
  );

  return value;
}

Usage:

function MyView({ observable }) {
  const currentValue = useObservable(observable);
  return <Text>{currentValue}</Text>
}

Note: it is best to use ObservableBehavior so that the observable.value can be accessed synchronously for the first render

[kilbot]

I'm just getting started with WatermelonDB, Observables and React hooks. I had some problems with the above code causing endless re-renders .. I suspect due to the ObservableBehavior as mentioned, but I don't fully understand what that means 😞

However, I did have success with this useObservable library, so I thought I'd just leave it here in case it helps someone else 😄

[kilbot]

The useObservable hook I am currently using is:

import { Subject, Subscription } from 'rxjs';
import { useEffect, useMemo, useState } from 'react';

export default function useObservable(observable, initial, inputs = []) {
  const [state, setState] = useState(initial);
  const subject = useMemo(() => new Subject(), inputs);

  useEffect(() => {
    const subscription = new Subscription();
    subscription.add(subject);
    subscription.add(subject.pipe(() => observable).subscribe(value => setState(value)));
    return () => subscription.unsubscribe();
  }, [subject]);

  return state;
}

Usage:

function MyView({ observable }) {
  const currentValue = useObservable(observable, 'initial', [observable, triggers]);
  return <Text>{currentValue}</Text>
}

I was going to post a PR to this repository ... but import { useObservable } from '@nozbe/with-observables' feels a little weird. Perhaps it would be better to have some sort of monorepo for hooks? Especially if @brunolemos has ideas for more hooks 😄

[radex]

I was going to post a PR to this repository ... but import { useObservable } from '@nozbe/with-observables' feels a little weird.

I know! I think it's best to post it anyway, and then figure out what's the best name… I imagine withObservables will be obsolete/deprecated in a year when everyone switches to Hooks anyway...

[radex]

@kilbot as for your hook, I think it would be cleaner and more performant to avoid extra Subject, and just set state based on observable subscription. Another issue is the need for initial prop. If you have it - it's great, but it would be best to use Suspense to prevent further render and just wait until we can get our hands on the value subscribed to. WDYT?

[kilbot]

I was having a problem with endless loops, ie: the first subscription was setting the state which triggered a rerender which started the process again. The extra Subject was an effort to get around that. However, I only started learning about observables when I wanted to use WatermelonDB .. so I'm a bit out of my depth 😓

I started rewriting the example app for WatermelonDB with typescript and hooks - mostly as a learning exercise for myself - I'll take another look at it this weekend to see if I reproduce the rerender issue I was having in my app.

[kilbot]

Hi @radex, I've created some example code to illustrate the infinite loop problem I am having. Please compare these two Netlify builds: useObservable with extra Subject and useObservable without. You'll see the subscribe/unsubscribe loop in the console.

Click here to compare the code(updated below) and here is the initial subscription which causes the problems.

It's a bit tricky to share code because I can't load everything into CodeSandbox .. but let me know if you spot anything!

[kilbot]

I've just had a look at this again with fresh eyes and realise it is the removal of the observable as a dependency not the addition of the Subject which stopped the infinite loop, eg:

export default function useObservable(observable: Observable, initial?: any, deps: any[] = []) {
  const [state, setState] = useState(initial);

  useEffect(() => {
    const subscription = observable.subscribe(setState);
    return () => subscription.unsubscribe();
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, deps);

  return state;
}

This seems to work okay.

It goes against the advice from the React team to remove the observable dependency, so there still may be some issues that I'm unaware of ... I'll have to do some more reading 😅

[ericlewis]

This seems very similar to how react-apollo-hooks works!

[radex]

FYI! I'm working on a fully supported, tested & high-performance solution for hooks :)

This is not easy, because:

• asynchronicity means we might not have the data on first call to useObservable, but caching means we might have
• hooks can't cause the component to bail out early and return null (the way HOCs can)
• Suspense is not fully supported yet
• there's no support for disposing resources for uncommitted renders, which means we have to do some hacking to get the right performance & DX (See: [Concurrent] Safely disposing uncommitted objects react/react#15317 (comment) _

here's some snippets of the work I'm doing.

Basic useEffect-based implementation:

export const neverEmitted = Symbol('observable-never-emitted')

export function useObservableSymbol<T>(observable: Observable<T>): T | typeof neverEmitted {
  const [value, setValue] = useState(neverEmitted)

  useEffect(() => {
    const subscription = observable.subscribe(newValue => {
      setValue(newValue)
    })
    return () => subscription.unsubscribe()
  }, [observable])

  return value
}

WIP highly-optimized implementation, but one that only works on BehaviorSubjects, and cached Observables (essentially, observables that can emit a value synchronously):

export function useObservableSync<T>(observable: Observable<T>): T {
  const forceUpdate = useForceUpdate()

  const value = useRef(neverEmitted)
  const previousObservable = useRef(observable)
  const subscription = useRef(undefined)

  if (observable !== previousObservable.current) {
    throw new Error('Passing different Observable to useObservable hook is not supported (yet)')
  }

  if (subscription.current === undefined) {
    const newSubscription = observable.subscribe(newValue => {
      value.current = newValue

      if (subscription.current !== undefined) {
        forceUpdate()
      }
    })
    subscription.current = newSubscription
  }

  // TODO: GC subscription in case component never gets mounted

  if (value.current === neverEmitted) {
    throw new Error('Observable did not emit an initial value synchronously')
  }

  useEffect(() => {
    return () => subscription.current.unsubscribe()
  }, [])

  return value.current
}

The plan is to take advantage of Suspense (or simulated suspense using error boundaries), so that you can just call const value = useObservable(query), without having to worry about initial value, and it does the right thing.

But you'd still have to wrap it somewhere with a <Supense> or a custom <ObservableSuspense> or something like that. I don't think there's a way around it.

I'd also like to publish an official prefetched component, so that you can do:

<Prefetch observables=[query, otherQuery, etc]>
  <SomeComponentTreeThatUsesUseObservableHook />
</Prefetch>

this would be much faster than relying on suspense, since you can start db operations early, and by the time you get to rendering components, you have a synchronous data source, instead of constantly rolling back partial renders.

Would someone be willing to help out with writing tests for this?

[kilbot]

This is great @radex! I would be keen to help out in any way I can.

I'll leave a link to mobx-react-lite here, just in case it is useful. There is a discussion on getting MobX to work with react hooks in concurrent mode, I guess there may be some parallels for WatermelonDB?

[radex]

@kilbot Thanks! I've seen that thread and mobx-react-lite, and I was planning to spend some time next Friday digging deeper into it to understand how they did it ;) Although MobX doesn't really have asynchronicity issues AFAICT.

[danielkcz]

Just want to point out we have mobx-react-lite@next which includes experimental support for Concurrent mode. Feel free to try that.

[radex]

@FredyC Thanks! I'll check it out!