**Feature:** OperationalContext hook useOperationalContext

[adeelibr]

Summary

Keeping the current render props implementation in tact, add another function called useOperationalContext which returns the current context of OperationalContext.

Uses Hydra pattern https://americanexpress.io/hydra/

usage

import { useOperationalContext } from "../src/OperationalContext/OperationalContext"

const Foo = () => {
  const ctx = useOperationalContext();
  return <p>Window width is {ctx.windowSize.width}</p>
};

P.S: I have not commited package.json with the updated react & react-dom version, should I for this PR?

CC: @fabien0102 @TejasQ

Related issue

#908
#910

To be tested

Me

• [x ] No error or warning in the console on localhost:6060

[TejasQ]

P.S: I have not commited package.json with the updated react & react-dom version, should I for this PR?

@adeelibr 💯% yes

[TejasQ]

@adeelibr let's add an example to the README so we see it in the playground. 😉

[adeelibr]

Can you kindly review again. @TejasQ

[adeelibr]

I made one small change in OperationalContext.tsx

+  const OperationalContext: React.SFC<Props> = props => {
+    const ctx = useOperationalContext()
+    return <React.Fragment>{props.children({ ...ctx })}</React.Fragment>
+ }
-  const OperationalContext: React.SFC<Props> = props => (
-     <OperationalContextOriginal>{props.children}</OperationalContextOriginal>
-  );

This was based on https://americanexpress.io/hydra/ Which uses context under the hood, to support render-props. This way we don't have to manage both of them at the same time.

It is working fine at my end, on the local dev-server. I don't know why the deployment is failing here.

I tried running this in the dev-server, it works fine.

<OperationalContext>
            {operationalContext => (
              <p>{`The viewport is ${operationalContext.windowSize.width} pixels wide and ${
                operationalContext.windowSize.height
                } tall.`}</p>
            )}
</OperationalContext>

[adeelibr]

Never mind, I forgot to export OperationContext consumer, which is being used in some other components. Thank God for test cases. 😅 ❤️ 🙉
Can you kindly review again. @TejasQ

[TejasQ]

@adeelibr you got it. @fabien0102 let's review this. 🚀

[TejasQ]

@adeelibr @fabien0102 one final thing that concerns me, is that if this component is used in a class component, the hook will throw for no fault of the user and be a very surprising breakage iiuc. Can we protect against this somehow?

[fabien0102]

@TejasQ Can you add an example for context? I don't really when what throw 😄

[adeelibr]

The new linters rule will specify that hooks should not be used in class components. I don't see a work around for this I am afraid.

[TejasQ]

@fabien0102 @adeelibr

here's an example

// Legacy code

class MySomething extends React.Component {
  render() {
    return (<OperationalContext>
      {({ pushState }) => <a onClick={() => pushState('/my-chicken-loves-me')}>HELLO 🐔❤️</a>}
    </OperationalContext>)
  }
}

The new OperationalContext will throw

Hooks can only be used in React function components

and the whole app will revert to an error boundary or unmount. The user will be like 🤔 wat

[adeelibr]

The new OperationalContext will throw

Works fine at my end, doesn't throw an error & it won't throw an error. Because we are using that hook inside our render prop component. The way people access it using render-props it won't cause an error.

Reference: https://americanexpress.io/hydra/

So the new changes are not breaking changes, this PR ensures that the current implementation doesn't break while ensuring that the new implementation also works. This will make it easy to transition slowly in your entire application to use context the new way. (If you decide to refactor)

[TejasQ]

@adeelibr I love you let's add more hooks WOOOOOO