Live data from Hacker News

Show HN: React Resolver – Async Rendering and Data-Fetching for React

github.com

1–10 of 11 posts

Re: Show HN: React Resolver – Async Rendering and Data-Fetching for React

#5

Is React Resolver related to React Nexus[1]? [1] https://github.com/elierotenberg/react-nexus

Hey Elie! Not directly, no. It looks like both of our projects originated from "real world apps" (as you say) with SEO requirements and, in my case in particular, ensuring mobile users get a response ASAP before React progressively enhances the page.

It looks like we've landed on about the same architectural solution given React's synchronous nature.

I'll have to check it out in more detail as, to be honest, I was more aware of the Nexus Flux library.

Re: Show HN: React Resolver – Async Rendering and Data-Fetching for React

#6
post #2

Nice to see some effort in this area. How is it compatible with the flux architecure?

Seems incompatible to me. You don't fetch data inside the components when you're using Flux.

but isn't the plan with Relay to do just that? or not?

Re: Show HN: React Resolver – Async Rendering and Data-Fetching for React

#7
post #2

Nice to see some effort in this area. How is it compatible with the flux architecure?

It works very well! React Resolver is handling the async-loading & rendering problem for you. How you choose to fetch & update data within your components is up to you :)

I have a very large application in production now using a custom flux implementation (since the flux wars have finally died down Alt & Redux taking the lead).

There'll be some documentation & examples around Redux specifically, but the gist is you'd do something like this (not using any Flux library in particular here):

  // Flux - watch UserStore for changes & provide "props.userStore".
  @connectToStore(UserStore)
  // Flux - provide actions as props for the resolver or component to use.
  @bindActions(function(dispatcher) {
    return {
      create: dispatcher.actions.User.create,
      save: dispatcher.actions.User.save,
    };
  })
  // Resolver - 
  @resolve("user", function({ create, userStore }) {
    return userStore.getCurrent() || create("New User");
  })
  // Now your component always has the latest, updated user
  export default UserProfile extends React Component {
  
Watch the repo for some more examples, as there'll be both Alt & Redux examples.

Re: Show HN: React Resolver – Async Rendering and Data-Fetching for React

#8
post #2

Nice to see some effort in this area. How is it compatible with the flux architecure?

Seems incompatible to me. You don't fetch data inside the components when you're using Flux.

It's compatible, as this is live in production today with a Flux library, and there are Alt & Redux examples in the works.

How you choose to fetch data is up to you, whether you use Flux, or fire AJAX calls within the `@resolve` function.

That's your code, not mine. I just make it so you can put your data requirements _beside_ your component instead of several layers up :)

Re: Show HN: React Resolver – Async Rendering and Data-Fetching for React

#9

Earlier quoted context omitted.

Seems incompatible to me. You don't fetch data inside the components when you're using Flux.

but isn't the plan with Relay to do just that? or not?

You're correct in that Relay correctly identified the same architectural problem with having data requirements _far away_ from the components that actually need it.

This is why React Resolver was created, and from what I've seen, also spurred React Nexus & React Transmit as well.

On an related note, v1 of React Resolver explicitly stated how it was similar to Relay with regards to fetching data for components. I've since dropped that messaging to avoid confusion since Relay isn't even available yet :)

Re: Show HN: React Resolver – Async Rendering and Data-Fetching for React

#10
This is nice but I can imagine it would still require a lot of boilerplate code in order to integrate nicely into a flux architecture in a production app. Comparatively, I think Fluxible does a good job in separating the async logic while providing you with clean Flux terms. Would be interested to see some higher-level integration library with Redux, Alt or a flux library.
Post reply on HN