https://discord.umbraco.com logo
Join Discord
Powered by
Stores and repositories
# package-development
w
So are stores necessary?
Reading @Kevin Jump post seems like you say ‘stores’ are overkill. So I’m curious to hear more from @Jacob Overgaard or @Niels Lyngsø on perhaps why I should use it? Apart from following the same convention you lot do. Is there a reason that I am not understanding?
j
that's a very philosophical question; depends entirely on your use-case... do you want to iterate a list of results in your component? then make a fetch call directly in your component and do that do you want to share state between components? pass it down through a property do you find that you all of a sudden pass properties to properties to properties 3+ levels deep? a store might be the solution for you do you think that other components might need the same data? a store might be the solution for you the answers to the question posed 8 years ago still hold up: https://stackoverflow.com/questions/29075534/in-react-js-when-should-you-use-a-store-vs-directly-manipulating-the-views-sta
we chose to implement the pattern everywhere in the backoffice, because we are in the "might" territory - we don't really know what people would use our data for, and we wanted to stick to the same paradigm throughout the source code so as not to confuse people on why we would do two different approaches
however, in the backoffice we expect you to spin up a repository instance, which does the calls, however currently there is no way to access the data of the store behind the repository, as we haven't yet implemented the feature we are calling "repository caching"... we want the repositories to be able to go: "Oh, I already have the data available that is being requested, so return that in lieu of making a new request" but we don't have that yet, so currently it will do a lot of network requests, but as long as you stick to that pattern, it will be automagically fixed for you at some point
w
OK thanks for the Why. Least I can try and read up and follow along.
n
Also notice a subtle but minor feature of backing a repository with a store, which is this example: Lets say i load a Item in the sidebar, via the respository. Then I load the same item in the main view via the repository. Then I rename the item in the main view. Then because there is a store behind, which gets updated as well, then the item got renamed. Then the item of the sidebar is also updated — cause it was observing the data of the repository. (And since the repo was backed by a store, then that established the shared data and thereby ensuring all users of a set of data is up to date with latest.) 🙂
But I would say, this is only relevant if you are building content manegement parts. For the usual Property Editor / Dashboard / Workspace Views this would be overkill.
w
OK in my scenario seems like I won't need this pattern as my first simple package just helps display something so no CRUD stuff and fancy updates everywhere. But someona at Spark's hackathon can tell me what I have done is all trash and do it over againb 😂
n
I would say, its your package, and you know the scope, in most cases a native JS Fetch call can solve the needs 🙂 so nothing wrong in picking your own selection of concepts
w
Yeh think until i become more familiar and comfortable it just feels overkill right now for one simple get request i need to do as no edits or deletes needed etc
PreviousNext
Powered by