Closed dacz closed 8 years ago
@dacz
This is a little on my part with poor docs, but with the help of some utilities from MobX itself and yourStore.object
you can do this.
You can use toJSON from MobX (which I believe is also about to be aliased to toJs
later when the 2.2 release of MobX happens) with store.object
to get the current state of the store.
store.object
is the behind the scenes object that holds all your state.toJSON
turns that into a regular object because if you try to print store.object
normally you'll get a bunch of junk included.import { toJSON } from 'mobx'
import mobxstore from 'mobx-store'
const store = mobxstore({ test: { a: 1, b: 2, c: 3 } })
// This will log the state of the store as an object
console.log(toJSON(store.object))
// To log it every time anything changes
store.schedule([() => console.log(toJSON(store.object))])
Does this help at all?
@AriaFallah Thanks, that helps. Actually I was doing something like this in my playing with mobx and your store (I used JSON.stringify).
I'm considering rewriting current app I'm working on (Redux) to mobx and mobx-store. But the store holds hundreds of items na it is quite convenient to see the store like I can see it in Redux dev tools. I'm considering to make something like this. What do you think?
Is there any possibility to monitor (and log) which changes happened on the store? Kind of "update log". It would help pretty much with debugging and testing.
Thanks a lot for your help and great library. For another project I was considering to use lowdb (I like the API) and bam - your library uses the the same API.
@dacz
__past
. I use it in my code here and tests here if you want examples. Although since MobX uses mutation instead of being immutable like redux, it stores not the previous state of the object, but how it mutated.remove
function mutates the order of your array in order to find the element to remove, and this causes undo/redo
to undo those intermediate changes. Instead I like to use lodash/fp
methods, and replace the contents of the entire array like import { remove } from 'lodash/fp'
const data = store('data')
data.replace(remove({ id: 1 })(data))
store.contents()
that gives you everything in the store in a plain object? It would be equivalent to the toJSON
, but behind the scenes.Thanks a lot for your help and great library. For another project I was considering to use lowdb (I like the API) and bam - your library uses the the same API.
LowDB inspired this actually, but I think I've made it a little better haha. I've replaced it with mobx-store
in all of my own personal projects where I used it.
I think that's it.
I'm going to close this for now, but I'll reopen it becomes relevant again. Feel free to continue the discussion if you have anything to add.
Note that an explicit update log with all mutations will be part of MobX 2.2 and the accompanying devtools. You can even try it already (manually, without the devtools) by installing mobx-react@2.2.0-beta.1 and logging the (relevant events) by calling mobx.spy(eventListener)
Op ma 23 mei 2016 om 00:49 schreef Aria Fallah notifications@github.com:
Closed #28 https://github.com/AriaFallah/mobx-store/issues/28.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/AriaFallah/mobx-store/issues/28#event-668345961
@mweststrate
Yeah I'm waiting on the official release and official docs for 2.2, and then upgrading when it's out. I could probably add some more cool features with spy, reaction, and action.
@AriaFallah Thanks for your answer and tips (and feedback from @mweststrate, too). I'll look into it and into 2.2 beta. I'm about to move my project from redux to mobx and I'm sure I'll learn a lot on the way :).
According something like store.contents()
… I think that it would be nice, especially to the newcomers (as I'm).
Please, do you have a tip for good practice to pass around the store? Using context like redux connect does?
Maybe there would be nice to have some mental comparisons with redux (even I know that mobx is about changing the mindset, slightly). I'll try to document my experience from redux to mobx to have some examples. Is it worth of?
According something like store.contents() … I think that it would be nice, especially to the newcomers (as I'm).
I added it. You can see an example usage here where I put the store into localstorage.
Please, do you have a tip for good practice to pass around the store? Using context like redux connect does?
I use a combination of props and context and it's worked well for me. In my experience, I use context because passing the store with react-router is more difficult then it should be, and then I use props for everything else.
Maybe there would be nice to have some mental comparisons with redux (even I know that mobx is about changing the mindset, slightly). I'll try to document my experience from redux to mobx to have some examples. Is it worth of?
For me at least, the mobx-store is really similar to redux. It's a store of stores that you can pass around everywhere. Eventually, I think I can build a mini-framework around it, but for the time being I think the biggest change from redux is that there is no "way" you have to do things. There's no structure you're forced into following. You really could make reducers and actions if you wanted to, and just pretend MobX is redux haha.
Another big thing is that you can have multiple mobx-stores. Normally, you only need one like with redux, but lets say you're building a very general component with its own state. Then it's fine to make another store for that. With redux, you always have to find a way to hook third party components into your main store, which can get complicated.
The more I know about mobx and mobx-store, the more I like the concept. It deserves to get mainstream.
Thanks for tips, very valuable. In redux I use HoC. But as Michel explained me, it's good to decorate most of the components with @observer, then (as Michel mentioned somewhere) there is no need to use HoC so much and just have 'active components'. Just to deliver them the store…
You mentioned react-router - I plan to listen to history that will update mobx-store with routing data and then in components fire async actions that loads data based on routing data from store (if not already loaded). Similar approach as with redux.
It strikes me now with full force what you've mentioned - that it si much more easy to create reusable components and packages with their unique stores. That's great, indeed.
Thanks Aria a lot for your help and tips.
In development mode it would be nice to inspect the store content (especially when it can be time travelled). Some kind of DevTool?