Closed ziflex closed 8 years ago
What do you mean by
In fact, it forces you to mutate you data inside your components which from my perspective is wrong.
@taion, I'm talking about this:
Relay.Store.update(
new RemoveCompletedTodosMutation({viewer, todos})
);
In real world app, usually it's not just and add a comment or update state of 'to-do' item. Usually, it's a bit complicated with some logic. And putting all that stuff inside components... well, this code smells, for me.
You can think of mutations as being effectively like Flux actions, and Relay.Store
as being analogous to the dispatcher.
They're not entirely the same, but Relay manages all the Flux-like concerns for you - it's like the only APIs you have are dispatching actions/mutations via Relay.Store.update
and requesting data via Relay containers.
@taion it works for simple cases, without extra logic. Otherwise, your components will contain not only ui logic, but business logic too.
In general, you'd put mutation-specific logic in the getVariables
method on the mutation class.
@taion ehh, putting business logic inside mutation class... you didn't convince me :)
Where do you put your business logic right now?
The point being that mutations are in this context fairly well analogous to Flux actions and action creators, with the full, elaborate Flux hierarchy slightly collapsed (Relay just has the Relay store, so separating the dispatcher from the store isn't relevant).
In general you shouldn't have a need to wrap up mutations with actions or whatever; mutations themselves are roughly analogous to actions as-is.
You may find it useful to integrate Relay with Alt or another Flux library, but that would largely be for purposes of managing local state, which is a bit different. I'd recommend spending a bit more time familiarizing yourself with Relay paradigms and working through a few of the examples before deciding that novel API abstractions are appropriate.
Have you used it in production?
Relay isn't "just" out - it's been around since August. We've replaced our largest internal app with a version that uses Relay and are in the process of migrating over all of our external-facing apps right now.
Mutations are pretty much drop-in for actions. Instead of doing
FooActions.updateFoo(args);
I do
Relay.Store.update(new UpdateFooMutation(args));
And any preliminary client-side processing goes from the action definition to setVariables
on the mutation.
And any preliminary client-side processing goes from the action definition to setVariables on the mutation.
@taion can you describe it in more details? And what about app state? For me, this model is still too simple for handling true SPAs.
Local state management isn't present in Relay yet. For many cases, however, where most of your app state is synchronized against a backend by Relay, the amount of residual transient state is sufficiently restricted that you don't need anything particularly powerful to manage it.
This is getting a bit off-track from the initial question though - I think what you're asking for doesn't really make sense in the context of Relay.
If you're interested in discussing client-side app design with Relay, there are active channels on both the Reactiflux Discord and the GraphQL Slack, and I encourage you to go there.
We should close this issue if there's nothing more to talk about that's directly relevant.
@taion thanks, will check these channels!
Hi there, Relay is finally released and probably many of you are trying to figure out how to use it :)
Recently, company I'm working for, started the project where they want to use GraphQL and Relay. Therefore, I started digging in and realized that Relay replaces Flux's stores but don't provide any actions. In fact, it forces you to mutate you data inside your components which from my perspective is wrong. And then I started thinking about abstraction around it and came up with idea - use Relay with Alt infrastructure but without its stores.
Or maybe it should be another framework?