#fluxjs

/

      • Falstaff
        I guess it depends on which implementation you go with (some I think hide the dispatcher from you) but I believe you generally are supposed to just have a single dispatcher, it's really just a means of handling the details of tracking which store is interested in which actions, so when an action is dispatched, it knows who to tell
      • you'll end up with multiple stores which may or may not be interested in multiple actions, and the dispatcher basically just handles the routing
      • of data between the stores and actions
      • jrm2k6 joined the channel
      • cvitullo joined the channel
      • cvitullo joined the channel
      • drikoda joined the channel
      • greves joined the channel
      • drikoda joined the channel
      • vjeux joined the channel
      • drikoda joined the channel
      • heavyhorse joined the channel
      • jrm2k6 joined the channel
      • Tom_ joined the channel
      • Tom_
        Good morning
      • Anyone here who can help me out? I have some questions about designen a rather big web app :).
      • *designing
      • jrm2k6 joined the channel
      • Trangar joined the channel
      • Trangar_ joined the channel
      • Trangar joined the channel
      • noone around? :)
      • Thorn joined the channel
      • Trangar
        Nope
      • Tom_
        Damn :D
      • Anyone can help me out with flummox?
      • hokkos joined the channel
      • sjzurek joined the channel
      • Anyone can help me out with flummox?
      • sjzurek has quit
      • sjzurek joined the channel
      • twentyseven_ joined the channel
      • heavyhor1e joined the channel
      • loremipson joined the channel
      • loremips_ joined the channel
      • Hey
      • Can anyone help me out with a routing question?
      • loremipson joined the channel
      • jrm2k6 joined the channel
      • Falstaff joined the channel
      • cvitullo joined the channel
      • Tom_ has quit
      • loremipson joined the channel
      • poppedco1n joined the channel
      • Falstaff joined the channel
      • jrm2k6 joined the channel
      • vjeux joined the channel
      • TheAceOfHearts joined the channel
      • warz joined the channel
      • warz joined the channel
      • timoxley joined the channel
      • timoxley
        I have a search input field which controls the results in a list. Where should the search input state live?
      • A store? In the parent component that controls the list?
      • also, the filtered list, should that data live in a store or is that a view concern?
      • Falstaff
        timoxley, the search input should be in the store, (I assume you have stores since you're asking in #fluxjs), as for the filtered list, the source list should be in the store, and the filtered list should be generated in the component's render and not stored anywhere
      • timoxley
        Falstaff: right. Ok, thanks.
      • Sp3d_ joined the channel
      • Sp3d_
        Hi there
      • What do you guys name your stores?
      • Do you follow any conventions? Like do they represent the resources or the domain?
      • Falstaff
        SomethingStore
      • where Something depends on what it's a store for
      • Sp3d_
        Like I have a store that I'm using to populate the Care Team section, but the server resource used is UserPatient
      • Falstaff
        mine are more related to the components that use it
      • Sp3d_
        Is it better to represent the domain of the react app? or What is being stored inside the store?
      • Falstaff
        I mean, whatever makes sense for you I guess
      • maybe you should just have a PatientStore
      • Sp3d_
        Oh, and that segways nicely into my next question...
      • If you're showing a list of Users, vs just one user....do you have two stores or just reuse the UsersStore to show one user?
      • warz
        in an app im working on, ive got a store that holds a collection of forum posts basically. the posts are paginated though, so i dont load hundreds of thousands of posts into memory. so the store has the array of the 20 posts that are displayed on an index view.
      • a detail view checks that collection for the available post. if its in it, it uses it.
      • if it's not it fetches it from the api.
      • or, server i should say.
      • both the collection of posts, and the individual post for the detail view are stored in the same store
      • vjeux_ joined the channel
      • Sp3d_
        I see...
      • Falstaff
        yeah I would be fine with having an array of items, with say a 'details' property, which you can arbitrarily fill either when loading the list, or later when specifically loading up that one item
      • jrm2k6|work
        warz: that does make sense. I use the same "pattern"
      • Sp3d_
        So where does the logic go to decide if you need to pull the details? In the action or in the store?
      • cvitullo
        definitely store
      • actions shouldn’t have logic
      • Sp3d_
        But if the store needs to call out to an api to fetch the details, shouldn't that be initiated by calling an action?
      • Falstaff
        this is where it gets sort of, implementation-specific. at least how I've solved that in my case, since I'm using marty.js, which offers a fetch API as a declaritive way of specifying when to get data remotely
      • cvitullo
        the action should trigger the store to do some logic, but the action shouldn’t contain that logic itself
      • Falstaff
        basically my view simply knows it needs to access a certain property which is wired up to my store's 'fetch' method, which defines a local and remote way of grabbing the data.. once the app gets into a state where it needs new data (ie in my case, when the user selects from a list in a dropdown), then the declaritive bindings retrieve the data and store it locally and then feeds that to the view
      • Sp3d_
        In fluxxor, I see assertion violations when I try to call an action from a store
      • Falstaff
        so the view doesn't directly say "go and get this data", it says "I need this data" and the store goes "oh, I don't have it locally, I'll get it", and that triggers an action on successful response which stores the data locally, which triggers the view to update
      • cvitullo
        yeah, strictly speaking you shouldn’t dispatch another action until everything has settled
      • fluxxor is one of the stricter implementations
      • Falstaff
        ah, yeah actions calling stores and stores calling actions is sort of a grey area
      • my implementation is ok with doing either, but simply because of using webpack I have to choose between one or the other, or else I get cyclic dependencies from both files 'requiring' each other which breaks everything
      • cvitullo
        falstaff: ideally, the view should say to the stores “hey something just happened, give me the data i need to render” rather than directly fetching what data it needs
      • Sp3d_
        Ok. So pulling additional data should be put into the view/component, to trigger an action
      • Falstaff
        cvitullo, that's basically what happens, I probably didn't explain it well, but my views only know that they get their data from props. My flux implementation wires up props to the store. the store handles grabbing the data in a relatively transparent way.
      • cvitullo
        yeah sounds good, just wanted to clarify that
      • Sp3d_
        Do you guys use the same store to get details and to edit details?
      • Falstaff
        Sp3d_, flux doesn't really tell you how to get data into a store.. that's sort of up to you. but as far as the view is concerned, it only cares about getting it's data from the store, however that's done in your implementation (ie you might access the store directly, in my case I have container components which wrap my actual components to handle the bindings)
      • Sp3d_, yeah I would
      • warz
        the logic that decides when to fetch data, in my code base, is inside my react components. the logic that actually fetches the data is within my actions. i am using flummox.
      • cvitullo
        the way i tend to add data to a store is just having the store itself make an ajax call, with a callback that introduces the data and passes it back to the view
      • so the views don’t even know if the data is coming remotely or from what’s ‘cached’, it just takes slightly longer if it’s not already loaded
      • Sp3d_
        It feels like there should be another layer to coordinate between the stores
      • Or maybe it should be done in the action
      • cvitullo
        actions should be as dumb as possible, as i understand
      • Falstaff
        cvitullo, stores are supposed to be syncronous
      • cvitullo
        where’d you see that? not doubting you, just haven’t seen it
      • Falstaff
        hm let me find it
      • cvitullo
        it’s the cleanest way i’ve been able to implement it
      • no actions fired from stores, no logic in actions, and components don’t know how the data is coming
      • Falstaff
      • "Asynchronously executed callbacks should not leak into Stores. The consequences of it are just to hard to fully foresee. This leads to elusive bugs. Stores should only execute synchronous code. Otherwise they are too hard to understand."
      • I guess that's not technically an official statement from a creator behind Flux or React or anything, but I think I've seen it elsewhere that stores should be syncronous code only
      • So further to that, what I've done in my code is through this Fetch api I've got my stores deciding whether or not to do a query based on whether the data is already there or not, and then that query has a promise with a success and failure handler defined which both trigger new actions to handle either outcome. if it's success, the store's handler updates itself, which triggers a re-render, which triggers the view asking the store for the data, which now
      • the store can return the local data for.
      • cvitullo
        i think there’s a better way to do it that would let it be flexible enough to drop in a relay kind of adapter or something, something that would allow data fetching to be bundled
      • i feel like having something that handled all data requests and always returned a promise, regardless of whether the data was local or fetched, would work pretty cleanly
      • i guess it depends on how abstract you want your code to be
      • Falstaff
        yeah, I'm not sure if I'm in love with this implementation or not. it feels somewhat convoluted but I'm not sure how what you propose would be different
      • honestly it was easier for me to appreciate what adopting React did to my code vs what Flux has done. React felt like a net gain but Flux feels like I traded off some complexity for different but similar complexity
      • warz
        ive definitely feel that flux causes me to spend a lot of time trying to figure where to put what data
      • flummox does make those decisions pretty straight forward though
      • actions are where you fetch and return the data that will be used by the stores to update their state
      • so ajax, etc, all goes in your actions
      • Falstaff
        ah well off to pair program for a few hours, cheers
      • cvitullo
        yeah warz definitely agree with it making you think about where to put data a lot more
      • i think different implementations have different opinions of where to do what, which makes conversations like this more awkward if people aren’t on the same one
      • Falstaff_ joined the channel
      • Sp3d_
        So it sounds like it's still undecided if logic should exist in the action
      • The only other solution is to just create another store to separate the list view from the details view
      • vjeux joined the channel
      • warz
        what amount of logic? i dont see the problem with logic, as it pertains to retrieving data to be dispatched, being in actions
      • most of my actions end up being simple wrappers around ajax calls, as it is
      • vjeux has quit
      • vjeux joined the channel
      • Sp3d_
        Like deciding to pull for details if its not in the store already
      • loremips_ joined the channel
      • TheAceOfHearts joined the channel
      • loremipson joined the channel
      • Thorn joined the channel
      • Daniel15 has quit
      • Are store names usualy singular or plural?
      • Daniel15 joined the channel
      • warz
        i do that logic in my views. when mounting, check the store for the needed data. not in the store? trigger an action to fetch it.
      • TheAceOfHearts joined the channel
      • loremipson joined the channel
      • loremipson joined the channel
      • Trangar joined the channel
      • Trangar has quit
      • Trangar joined the channel
      • loremipson joined the channel