DonnyVerduijn
commented
9 months ago I honestly feel that MST or at least its philosophy, deserves more attention, but it might also need to incorporate for the needs that we have today. In my opinion, the future efforts into MST-GQL, should also be considered by taking that perspective.
If we compare MST to Solid.js and more specifically its Store API, we see that MST certainly benefits certain usecases, where it avoids reinventing the wheel. Solid.js its API actually refers to the use of the "createMutable" store factory method, for interop with external systems like Mobx or Vue, so it is reasonable to assume they understand there is a limit to what they should offer themselves.
That being said, i think that flexibility is key and the concept of having multiple stores, and the ability to combine them would be paramount to its success.
There's also a question how large the API surface should be, and which problems it is going to solve. One of the major features of MST, is the ability to reactively traverse the graph by index and create computed properties, where the API allows for a clear separation between the view model and the view.
Having interop with GraphQL stays relevant, because what is the point of enabling traversal without being able to populate the store? However we also have to acknowledge the popularity of tRPC because it is cutting down on ceremony and provides OOTB client/server type safety.
I'm fully aware this is far beyond what is possible under MST-GQL. It would require a different project, but is possibly relevant to consider, given we might want to consider such a project to be a direct replacement?
beepsoft
Hi all,
I just got maintenance rights to the repo from @mweststrate and will try my best to contribute to the progress of mst-gql.
I made attempts to contact the current (or former) maintainers, @jesse-savary and @Benz19, through all available communication channels without success, therefore, I haven't had the opportunity to discuss their objectives for the project. Nevertheless, I want to thank you guys for your work so far!
Considering the lack of development, communication, and new releases for 15 months, I decided to pick up where they left off, because I don't want to see mst-gql die.
I occasionally use mst-gql in my projects, and when I do, I often find the time - and the need :-) - to improve mst-gql itself, whether it's to address bugs or to add new features. My aim is to review and merge PRs, address bug reports, and engage in discussions about new features with the community - in a best effort manner.
Some time ago, Jesse initiated several discussion topics that are still of interest, and I would like to invite all of you to participate, particularly regarding features you wish to see in v1.0.0 or any challenges you face while using mst-gql.
Looking forward to your contributions and discussions!