New React Context API

[loganpowell]

Hi @cif ! Just read your Medium article on this and am super stoked that someone else out there is thinking what I'm thinking ™️ ;)

Might you be updating this to the latest version of React (16) and it's new Context API?

the gist:

React.createContext

[cif]

Hey @loganpowell, thanks for reading! This was (and still is) more of a POC, but I have used it for a couple side projects since its creation.

I'm totally down to work on this if nothing else to get my feet wet the new API. I read that same article when it was published a while ago and thought the same thing.

Any idea when they'll update official docs? https://reactjs.org/docs/context.html still looks like the same old "proceed with caution" doc to me

[loganpowell]

I think what you have is a brilliant Idea. I was just chatting on on gitter about this with another who is in the same camp.

As to

Any idea when they'll update official docs?

It looks like the new context is officially merged (https://github.com/reactjs/rfcs/pull/2) but I'm not sure when the docs will get updated. I'm taking a long shot and pulling in @acdlite, but doubt he'll have the time to answer us. I will subscribe to the PR.

Let me know if you want to work together to put a full example app together!

[cif]

Totally down to work on making this legit with you / any other contributors.

I'll keep an eye on that PR as well.

If you get around to first shot at integrating I will definitely make time to review, merge, add you as contributor etc.

[loganpowell]

Give me some time, but sounds good to me!

[loganpowell]

Have you seen Frint?

I think there's a company that's really bought into this idea:

https://medium.com/@fahad19/using-rxjs-with-react-js-part-2-streaming-props-to-component-c7792bc1f40f

[cif]

Cool, similar pattern for sure. Looks like app.context (ships with the opinionated framework?) composed with Rx stream to compute derived component state.

Generally speaking, if the website isn't strictly documentation (e.g. has a marketing feel to the index) and uses the term "framework", I stay clear ;)

On Tue, Feb 20, 2018 at 11:01 AM, Logan Powell notifications@github.com wrote:

Have you seen Frint https://github.com/frintjs/frint/blob/master/packages/frint-react/src/components/observe.js ?

I think there's a company that's really bought into this idea:

https://medium.com/@fahad19/using-rxjs-with-react-js-part- 2-streaming-props-to-component-c7792bc1f40f

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cif/redux-fusion/issues/8#issuecomment-367082629, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXyGdv62O1u3JlHu5PHnR-ScBlci1jcks5tWxaPgaJpZM4SG1Gd .

[loganpowell]

haha... good point. I'm just collecting some references, so we don't reinvent anything and steal as much as possible. On that note, here's another:

https://github.com/zxbodya/rx-react-container

[cif]

Fair enough :) There's a lot of ways to derive component state from observable streams. I chose to use mapPropsStream with fusion due to its lightweight feel: https://github.com/acdlite/recompose/blob/master/docs/API.md#observable-utilities

My idea with fusion was to use Redux as the context given its widespread use (at that time) and the fact it implemented observable out of the box

FWIW there is a refactor PR still open. I don't really dig the fact it uses connect from react-redux which (what I was trying to replace), never heard back from the author after latest feedback.

[loganpowell]

Yeah, I like that you use recompose and just add a little extra spice to that rather than rolling your own HOC with overlapping capabilities. That's one thing that the other libraries that I'm finding tend to over-do, imo.

[loganpowell]

@cif sorry for the delay on this. I'm trying to set up a similar example to that which you allude in your blog posts. You might have guessed, it's a struggle to figure out how all the parts of a fully-realized reactive frontend go together (even for a simple example).

On this note, I could use some ideas for setting up a simple example with the following structure:

+------------+
| React      |     = Pure functional components
+------------+     
   |       ↑ ------- state$.pluck('hello').map(..)
   ↓ ------|-------- { stream: click$ } = createEventHandler
+------------+
| Recompose  |     = Observable Utilities
+------------+
   |       ↑ ------- Fusion
   ↓       |       
+-----+  +-------+ = Ramda lens [1]
| Axs |  | Store$| = Observable.from(store)
+-----+  +-------+ = Ramda lens [1]
   |       ↑ ------- 'thin' reducers
   ↓ ------|-------- 'thin' actions
+------------+
| Redux Logic|     = Async Orchestration [4]:
+------------+       - Router5 (routes as state) [2]
   |       ↑ 
   ↓       |       = access `client.query` here [3]
+------------+
|ApolloClient|     = Because GraphQL
+------------+
   |       ↑ 
===============
   ↓       |
+------------+
| GraphQL    |
+------------+

Notes/References:

• 1 I don't know if this is the best way to go, but I've got shiney object brain.
• 2 Decouple UI from Route state as we would any state from our UI.
• 3 instead of coupling Apollo directly to components (which is the way they seem to want everyone to go, but... coupling is bad), call apollo from middleware orchestration logic where it can be controlled with routing and other async/sync orchestration stuff.
• [4] Keeping reducer(s) and action creator(s) clean/pure/"thin"

I'm sorry if this looks weird. Let me know what you think.

[cif]

That's a killer setup! All the right building blocks IMO, think you'll have success with that. I worked next to a team using Ramda lenses and they had good things to say. Just followed you on Medium hope to see an article about it soon ;)

Glad you came across my posts, I planned on writing next about wrapping REST services with GraphQL and JWT authentication, but as with most things, time allowing.

Definitely keep me posted on any changes you make to Fusion or and riffs off that tooling. I actually have a somewhat greenfield project coming down the pipe at work...

[loganpowell]

Woot. Will do.

[loganpowell]

Oh man, you're gonna hate me for bugging you about this, but you've been nice to me, so I'm back with more time-wasting stuff from my explorations.

As you mentioned in your blog post about going around looking into how RxJS can work with React and discovering all the various shiny things out there that are headed in that direction, I am finding myself doing the same and wanted to compare notes (I apologize for delaying on fusion, but you may understand why:

1) Calmm: uses Kefir observables, atoms, lenses and a special React Implementation to enable observables to be used directly within the components.

2) Focal: fork and port of calmm that uses RxJS instead of Kefir, and some additional short-cuts that make state management super straight-forward (for those comfortable with lenses, atoms and observables). This library is used in production at Grammarly.

3) ReduRx: Also using RxJS for state management, but keeps the flux pattern.

The thing about Redux is that it is very nice for managing state in a conventional way, but when you think about what possiblities arise when you introduce observables as the fundamental data structure and how that can raise the level of abstraction in the code (and thereby eliminate a lot of ... boilerplatyness (I didn't want to say what everyone else says about Redux these days, so)) it seems natural that these kinds of solutions would pop up. Have you seen these?

[cif]

Those all look like pretty similar patterns for sure. Sorry for the delay, the closed issue status pushed this off the radar for a minute. Was talking to a co worker and got reminded of this just now.

Update on my end: For the new project I've adopted GraphQL. I think there still might be some cases for a global store or event bus model for UI sync actions like modal / notifications, but I don't think I will ever use Redux for async fetching again :)

Again, if you do end up writing something definitely post on Medium! Cheers!