Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Randall Harmon
    @rjharmon
    My takeaway is that arbitrary objects can be stored as references in the freezer, but they are treated as object-id's. Only when the freezer container where they are stored is modified (say, replacing /myThing.r.q with a different object), will any changes be triggered (myThing.r.getListener() will see a change of its 'q' entry from <my-class-y-thing> to some-other-object)
    Does that sound accurate @arqex ?
    Javier Marquez
    @arqex
    Hi @fjharmon
    freezer can store reference to other freezer nodes
    but any plain object/array that you want to store will be transformed in an freezer node one
    freezer nodes are immutable and also have custom method to update the freezer store, that's why it copies everything that is added
    ..everything but a freezer node
    you can do
    var f = new Freezer({myThing:{q:{q:3}}})
    and then copy the freezer node
    Javier Marquez
    @arqex
    var state = f.get();
    f.myThing.set({r: state.myThing.q})
    Then any change in myThing.q or myThing.r will change the other and trigger an update event in the listener
    Randall Harmon
    @rjharmon
    Good clarification @arqex - thanks
    Sergei Egorov
    @bsideup

    Hey everyone

    I'm having an app where I poll whole state (API is already provided, can't change it :( ) every second, and I want to use Freezer to figure our what was really changed and how should I react (funny, I use React for render :) )

    Can somebody point me at some examples or documentation of state merging?

    Randall Harmon
    @rjharmon
    @arqex I'd like to have the freezer.get() be automatically transact()'d, so that all the updates that may happen in the store during an action (e.g. app setup or user-triggered activity) are accumulated in the resulting tree, then committed on next tick, instead of producing multiple tree states. I expect I can manually arrange that in my code, but it seems like a valuable bit of function for the freezer itself. Thoughts?
    In this example, my test with --> shows that the new state (store.get() after run()) is not the same object as transact() is, which I'd have hoped was true.
    Randall Harmon
    @rjharmon
    Here's another one that might be related: transact() returns an object that can't set() - so freezer.get().transact().set("e", 42") fails with "..set is not a function"
    @arqex is that intentional?
    YPCrumble
    @YPCrumble

    @arqex I'm testing the following code on the JSBin:

    var test = store.get();
    test.set({updateOne: "first update"}); // returns an updated state appropriately.
    test.set({updateTwo: "second update"}); // weird - does not include first update.
    store.get(); // weird - this includes updateOne but not updateTwo

    Is it desired behavior that you can only use set() on test in this example one time? Is this what pivot is for/am I missing something?

    Randall Harmon
    @rjharmon
    @YPCrumble I can't really speak about the behavior that's "desired", but set() returns the replacement node, in which updateOne was applies.
    After that, the freezer stops watching the old tree for change, and watches the new tree instead. That's why updateTwo appears to go missing. In fact if you set tree2 = test.set(...updateOne...), and then call set(...updateTwo...) on tree2, you'll see both updates in store.get() at the end
    Hope that helps @YPCrumble
    alternatively, you can say store.get().set(...update1...) and store.get().set(...update2...)
    also, pivot() can be used, yes
    Javier Marquez
    @arqex
    New updates on freezer! With the latest v0.11.0 it is possible to store class instances inside a freezer's store. They will be handled as leave values by default :#
    YPCrumble
    @YPCrumble
    @rjharmon thanks, very helpful!
    Javier Marquez
    @arqex
    :)
    Randall Harmon
    @rjharmon
    leaf values @arqex ?
    such that nested data structures in by own-properties will be mutable and their changes not tracked
    Bernd Wessels
    @BerndWessels
    Hi, I can't figure out how object references can be preserved between states. Can you have a look at this issue please arqex/freezer#77
    Javier Marquez
    @arqex
    @BerndWessels in a fast look at your code I can see these lines as problematic ones
    state.app.human.set(0, {firstName: 'Bernd'}); state.app.dog.set(99, {name: 'Brutus'});
    See that when you set the first property to the human attribute, you are creating a new state inside your store
    so state is not longer the source of true, since after that set, state!== store.get()
    so the second set can be problematic
    In this particular case dog should be the same in state and store.get
    I'll have a deeper look at the issue when I finish working, and reply to you in github
    Ghost
    @ghost~567889a716b6c7089cbfce6b
    Anyone notice issues with Chrome 51? It may be a red herring, but I suddenly noticed weird behavior in my app using freezer and the only thing I can figure has changed is Chrome. I have a mouse-movement event generating a change to a freezer object. This obviously happens frequently and used to cause frequent update events by the freezer object, but now the updates only seem to tick ~1/second.
    Javier Marquez
    @arqex
    Weird, working for me nicely in Chrome 51.
    I have a svg editor that uses freezer and I can reproduce that kind of frequent updates.
    When working with this kind of real-time apps it's better to initialize your Freezer store in live mode:
    var store = new Freezer({ ...data here...}, {live:true})
    that will make the store to trigger the update event when the update is produced instead of batching the updates and trigger one event with all of them at the next tick.
    @schwiet are you using the live mode?
    Ghost
    @ghost~567889a716b6c7089cbfce6b
    @arqex I wasn't. And initializing to live mode did resolve the symptom I just started seeing, thanks! Any insight into why it worked before without live:true?. Also, note I'm using v0.9.6. Lastly, I've noticed I can only reproduce with mouse events, other frequent updates act as I was expecting. I would think that batching updates between ticks would work just fine, I wonder why I was only seeing ~an update / second.
    YPCrumble
    @YPCrumble
    @arqex thanks again for building this great library! I have a question for you - if you add this to the JSBin is it expected behavior that the "one" property of freezer.b is hidden?
    // Let's create a freezer store
    var freezer = new Freezer({
        a: {x: 1, y: 2, z: [0, 1, 2] },
        b: [ 5, 6, 7 , { m: 1, n: 2 } ],
        c: 'Hola',
        d: null // It is possible to store whatever
    });
    freezer.get().b.set("one", [1, 2, 3]);
    console.log('b is: ');
    console.log(freezer.get().b); // Why doesn't this include `[1, 2, 3]`?
    console.log('b.one is: ');
    // It's like the property is hidden because this returns `[1, 2, 3]` as expected.
    console.log(freezer.get().b.one);
    YPCrumble
    @YPCrumble
    @arqex my understanding is that this happens because b is set to an array, and this method is trying to assign a value to a nonexistent array index ("one"). Perhaps this should return an error rather than the current functionality, telling the user that this method is not possible on the immutable array? I'd be happy to submit a PR if that's helpful.
    Nivedha-Palani
    @Nivedha-Palani
    I got a weird issue. Sometimes, the set function is not working. the value is not updating in Freezer. Still i'm seeing the older value. Please help me to handle this. After this, Even a onclick method is not working
    Nivedha-Palani
    @Nivedha-Palani
    @arqex I got a weird issue. Sometimes, the set function is not working. the value is not updating in Freezer. Still i'm seeing the older value. Please help me to handle this. After this, Even a onclick method is not working