Explain difference between contexts and stores

[Vages]

I had a problem understanding why you would want to use a context when you can just use a store. This is what I've gathered after reading a bit about them.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR relates to an outstanding issue, so please reference it in your PR, or create an explanatory one for discussion. In many cases features are absent for a reason.
• This message body should clearly illustrate what problems it solves. If there are related issues, remember to reference them.
• Ideally, include a test that fails without this PR but passes with it. PRs will only be merged once they pass CI. (Remember to npm run lint!)

Tests

• Run the tests tests with npm test or yarn test)

[pngwn]

I'm not sure the tutorial is the best place for a discussion about the benefits of stores vs context, it is mainly there to show how to use these APIs. I appreciate that context is a more difficult API to get to grips with and we need to do a better job of explaining it.

This kind of information should definitely be somewhere, it might fit better in the API Docs although the API Docs are in danger of not being API Docs at all. Maybe they just need renaming.

I am unsure about where this should live.

[Vages]

You may be right, @pngwn, and I may be the only guy asking myself that question at this point. Perhaps the API docs are a better place for it, or perhaps some other tutorial page. I'm arranging a meetup at work about Svelte this coming Monday, so I may test it out on my colleagues to see if they understand the difference without my addition to the tutorial.

However, I really appreciate how the Svelte tutorial compares similar concepts and quickly explains the benefits of using one vs the other. For example, the subchapter on readable stores:

Not all stores should be writable by whoever has a reference to them. For example, you might have a store representing the mouse position or the user's geolocation, and it doesn't make sense to be able to set those values from 'outside'. For those cases, we have readable stores.

I thought that the context chapter would really benefit from such an explanation. If its the length of my addition that bothers you, I'll gladly revise it! 🙂

PS: I actually gathered my understanding from an answer of yours on discord, @pngwn, so thanks for that! 👍

[pngwn]

Having thought about it, I actually think that the first paragraph is a really good summary of stores vs. context, I don't really think the code example or additional tasks add much (I was a little confused about them). So, I'd be happy with this if we just kept that paragraph, it doesn't add too much length but it does clear up a question that we get a lot in a very succinct way.

[Rich-Harris]

I think we can combine the 'Remember that context is not inherently reactive' bit with this. I've updated the branch

[Conduitry]

This sounds good, but it's gonna bug me that the 'available to' is not italicized the first time it appears in the sentence but it is the second time in a parallel construction.

[Rich-Harris]

oof. mad that i missed that 😅

[Rich-Harris]

thanks @Vages!