Add ConsumeContext

[FabianHummel]

Add a function to directly consume contexts within JSX. Inspired by React's Context.Consumer component, but nicely integrated with this primitive's createContextProvider.

Tests have been added and source code + README.md is documented

[changeset-bot]

🦋 Changeset detected

Latest commit: e71e4ad

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solid-primitives/context	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[thetarnav]

this is a cool idea, but I don't like how you need a bound function (without parameters) to use it. When the default solid api for using the context is useContext(Ctx). At least it should be added to docs. To pass it as () => useContext(Ctx) or useContext.bind(null, Ctx)
Also you can easily do this in solid and it will have the same effect

<Provider>{untrack(()=>{constvalue=useContext(Ctx)return<>{value}</>})}</Provider>

[FabianHummel]

If you mean the useFn parameter, yes, it would be better to change it to the context directly. Maybe allow for either of one, because I really like simply passing the use function that is returned from createContextProvider, especially because createContextProvider does not return the raw solidJS context:

<ConsumeContextcontext={counterContext}>{(ctx)=><>...</>}</ConsumeContext>// or<ConsumeContextuseFn={useCounter}>{(ctx)=><>...</>}
</ConsumeContext>

And for the easy alternative: <ConsumeContext> solely serves as syntactic sugar, just like <Show>, <For>, etc...

[FabianHummel]

Implemented the aforementioned ideas and added tests + docs

[thetarnav]

what about

<ConsumeContextuse={useMyContext}><ConsumeContextuse={()=>useContext(MyContext)}><ConsumeContextuse={MyContext}>

by simply checking the typeof props.use?

Also it may be useful to mention in the docs that the prop will not be reactive.

[FabianHummel]

Oh, I totally forgot about this option, I will implement it later that day, thanks!

[davedbase]

Hey there! It's been quite a while since this was first introduced. We're working on Solid 2.0 migration right now and would like to consider this for the porting. Do you have time to finish off the current work for 1.0 or possibly support 2.0 directly?

[FabianHummel]

Hi, I am pleased to see this PR regaining some attention, it kind of went under my radar to be honest 😅

It's cool to see progress being made on SolidJS and I would still love to contribute to its ecosystem. I can invest some time updating this PR to Solid 2.0 if it's fine for you. Are there things I need to look out for like changing the branch, or can I continue work as usual?

[davedbase]

I'd recommend merging in main to ensure you're on latest and you can continue working as you'd like. Can land 1.0, publish and get a 2.0 or going. :)

[davedbase]

@FabianHummel just checking in to see if you're still interested in migrating this? We landed a next branch for our 2.0 effort. Would love to see your work migrated there!

[FabianHummel]

Hello @davedbase, I did manage to migrate my changes to version 2.0. However, due to internal changes to how Context now works in SolidJS, I need to rely on ugly checks and type casts to differentiate between a Context<T> and a use-function () => T | undefined, because they are now both of type function. Please tell me if there is a better way to solve this problem.

Also, do I need to create a new PR or can I somehow reuse this one? I created a new branch FabianHummel/solid-primitives:context-consume-v2 which should merge into solidjs-community:next if I understood correctly. Honestly, I haven't used GitHub for contributions in recent years.

[davedbase]

@FabianHummel you should branch off of the next branch and apply your changes to the primitive. You can then issue another PR identifying that the changes or relevant for v2. That would be easiest.