edemaine / solid-meteor-data

Integrating SolidJS and Meteor reactivity
MIT License
16 stars 2 forks source link

createSubscribe can't react #2

Closed edemaine closed 2 years ago

edemaine commented 2 years ago

Because the arguments to createSubscribe are not functions, the subscription (name or arguments) can't depend on any SolidJS reactivity. What's the right interface? A single function argument returning an array of arguments? Each argument can be a function?

Brendan-csel commented 2 years ago

Maybe each arg in createSubscribe(name, ...args) could be a constant or a thunk if it needs to be reactive (() => props.group) and just document that.

Internally you'd need to walk the args in an effect and call any thunks - then update the subscription. I don't know anything about Meteor sorry - so not sure if what I'm saying is implementable. 😄

[later in Discord] It has precedent I guess - like the Source argument to createResource is the same (either a constant or an accessor).

edemaine commented 2 years ago

I agree this would work (functions aren't valid arguments to subscriptions), and it looks pretty nice. I worry it might be error-prone: if you forget to wrap an argument in a thunk, you don't get reactivity... But given the precedent, maybe it's a good approach?

An alternative I wonder about is, like createFind has a find call nested within it, createSubscribe should too, like

const loading = createSubscribe(() => Meteor.subscribe('posts', props.group))

This is getting dangerously close to (i.e. not much shorter than) the equivalent

const loading = createTracker(() => !Meteor.subscribe('posts', props.group).ready())

but still avoids a bit of boiler plate. (We could actually define createSubscribe in terms of createTracker.)

An advantage of this style is that you could use a custom subscribe function that behaves similarly to Meteor.subscribe. There are a few libraries that provide alternate subscribe functions e.g. that add caching behavior, e.g. https://atmospherejs.com/ccorcos/subs-cache

A third alternative would be to provide both call styles... if the only argument is a function that returns a subscription instead of a string name, then it's clearly the latter style. Otherwise, it might be a completely static subscription (all arguments are explicit) or a reactive one with some thunk arguments.

edemaine commented 2 years ago

I ended up supporting both styles. Thanks @Brendan-csel for the feedback!