I have read the links. Those articles does not explain real practical downsides of fetching data inside a subscription.

Moreover is seems like fetching using an event encourages more imperative approach when you need to provide concrete steps for fetching data for each component instead of doing it in a more reactive way as when you fetch data from a re-frame database itself.

In re-frame, nothing "new" happens without an event. In turn, it is the associated event handler which knows how the event should change the world. In which case, it is event handlers which initiate (via an effect) the fetch.

The job of a subscription is to simply deliver data

it is reactive, not imperative.

Imperative stuff happens via event handlers (and the effects they nominate)

> The job of a subscription is to simply deliver data Why is there a difference between delivering from re-frame database and delivering from a server?

So in re-frame, views are not imperative. And neither are subscriptions. They are simply nodes in a reactive signal graph.

Delivering from a server is stateful and async, etc.

There are timeouts and failures, etc.

Let's imagine I have fired and event to deliver some data from a server and then I've rendered a component, which is subscribed to that data. Exactly as you suggest. It is async and prone to timeouts and failures too.

Yes, so the goal is to limit that kind of stateful logic to event handlers. Spreading that kind of logic around into views or their subscriptions is not recommended.

After all, if you want to, you can just put the GET into the view itself componentWillMount

Why bother putting it into a subscription?

But hey. If you believe you want to make subscriptions side-effect-y, the blueprint is there in that document. We certainly explored it and then backed away. But your experience may be different.

> After all, if you want to, you can just put the GET into the view itself componentWillMount You have provided good reasons not to do that. Especially that components become less reusable when they are coupled with requests.

It doesn't sound like I've convinced you

I'll put some more thought into my explanations, but that's all I got for the moment :-)

But subscriptions are about fetching data from a model, so I'm trying to understand why can't they fetch from the server.

Believe me I'm open to any explanations.

But at the moment is sounds like "Don't do that because Mike told you so" 🙂

No, not at all.

I just explained my reasons

But they were obviously not very convincing for you

For me, the reason is simple: don't make subscriptions have side effects.

Only event handlers should have side effects.

In our experience, that rule simplified things.

> For me, the reason is simple: don't make subscriptions have side effects. I expected something like "We did this in our project and that lead to this, this and that" rather than "should not have side effects because should not have side effects"

Believe me I do understand your general line and efforts to separate and isolate side effects. I just wonder if it worth it from practical standpoint.

If we could fire fetch events from subscriptions - we could care less about repeating fetch events in every view change event. This is a huge plus. But what are the downsides?

A more complicated computational model

Because side effects can happen in more places.

Everything is a trade off. I find it useful to keep the role of each domino clearly delineated.

I hope all that was useful. Gotta go.

Useful even if I didn't provide compelling reasons in your view

Nite.

Thank you!

@achikin I don't have much time right now but I slept on my explanations and would put my position like this ... We're programmers and we create abstractions for a living because it is our primary weapon for controlling complexity. As a result, when we hear subscriptions access data from app-db we're tempted to turn it into the more general (abstract) idea that subscriptions access data including from the server. I actually went down this path at one point (hence the documentation on how to do it) but realised it broke another more important abstraction in re-frame - the computational model. It makes subscriptions side-effect-y and there's always a cost for side-effect-y-ness. re-frame goes to a fair bit of effort to corral side-effects into just one place (one domino) because the overall architecture and the apps it produces are easier to understand as a result. State machines are simpler to understand than full Turing machines because of the constraints they impose on computation. re-frame constrains you too and (hopefully) produces a simpler computational model as a result. One of the constraints is that side-effect-y stuff only happens in one place. All of the above is pretty much what I originally said, but perhaps repackaged to make more sense. Maybe.

Vaguely related: https://github.com/Day8/re-frame/blob/master/docs/MentalModelOmnibus.md#on-dsls-and-machines