{"_id":"5615ce9f21e9110d007802a9","githubsync":"","project":"56000f0d8c0c9d0d00dcad21","user":"5600910981a9670d006d144f","version":{"_id":"56000f0e8c0c9d0d00dcad24","project":"56000f0d8c0c9d0d00dcad21","__v":13,"createdAt":"2015-09-21T14:07:10.176Z","releaseDate":"2015-09-21T14:07:10.176Z","categories":["56000f0e8c0c9d0d00dcad25","56008f2497f69f1700f21a36","560091601503430d007cc936","560e0d8054af2b0d005bbe92","560e3ce7ad6b200d00ff471c","560e3cf2c4e4ae0d00b42ed1","561c81d0e822e12b00e1fe00","561c81e9e822e12b00e1fe01","561c823d20b4a92b007d5147","56257f8951bf1c0d001f660a","562d5f165bd25e0d0054dbd4","562d68d5d38b650d0044472a","56421aebb0dc090d00f88438"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"category":{"_id":"561c81e9e822e12b00e1fe01","__v":2,"pages":["56207bb1bc7b320d007ddb05","5625ca89d0f87e190014c4d3"],"project":"56000f0d8c0c9d0d00dcad21","version":"56000f0e8c0c9d0d00dcad24","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-10-13T04:00:41.988Z","from_sync":false,"order":3,"slug":"spaceflux","title":"User Interface"},"__v":19,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-10-08T02:02:07.751Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"The biggest problem with Meteor templates is that they need to get their data from *somewhere*. Unfortunately there is no good pattern provided by the core team, so everyone has to come up with custom solutions. `space:flux` integrates with [blaze-components](https://github.com/peerlibrary/meteor-blaze-components), by providing a simple API to access reactive application state inside your components (provided by the stores).\n\nComponents hand over state to their managed templates, interpret (dumb) template\nevents and publish business actions. The stores listen to published actions and update their internal state according to its logic. The changes are reactively pushed back to the components that declared their dependency on stores by accessing their data\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/ZFw80l9RRO2zMJ6MWhrm_Flux.png\",\n        \"Flux.png\",\n        \"1729\",\n        \"768\",\n        \"#715446\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Data source is reactive\"\n}\n[/block]\nJust define a method\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"Space.flux.Store.extend(Todos, 'TodosStore', {\\n  …\\n  activeTodos() {\\n    \\n    return this.todos.find({ isCompleted: true });\\n  }\\n  …\\n});\",\n      \"language\": \"javascript\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Data source is non-reactive, but can be inferred from other state\"\n}\n[/block]\nAdd the function to the `reactiveVars` return array\nReactive vars should be used for values that can be inferred by state like the current route or computed data. These won't \"survive\" hot-code pushes but will be rebuilt on every reload.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Example\",\n  \"body\": \"Looking at the current route can determine the value, so after a hot-code push the value is restored.\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"Space.flux.Store.extend(TodoMVC, 'TodosStore', {\\n  reactiveVars: function() {\\n    return [{\\n      activeFilter: this.FILTERS.ALL,\\n    }];\\n  }\\n});\",\n      \"language\": \"javascript\"\n    }\n  ]\n}\n[/block]\nThis will generate an `activeFilter` method on your store which can be used to get and set the reactive var.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Data source is non-reactive, and cannot be inferred from other state\"\n}\n[/block]\nAdd the function to the 'sessionVars' return array\nSession vars should be used for values that cannot be inferred by routes or loaded data and should survive hot-code pushes.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Example\",\n  \"body\": \"Imagine a comment textarea where the user writes something. This should survive hot-code pushes and save the value!\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"Space.flux.Store.extend(TodoMVC, 'TodosStore', {\\n  sessionVars: function() {\\n    return [{\\n      editingTodoId: null\\n    }];\\n  }\\n});\",\n      \"language\": \"javascript\"\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"flux-in-depth","type":"basic","title":"Flux In-depth"}
The biggest problem with Meteor templates is that they need to get their data from *somewhere*. Unfortunately there is no good pattern provided by the core team, so everyone has to come up with custom solutions. `space:flux` integrates with [blaze-components](https://github.com/peerlibrary/meteor-blaze-components), by providing a simple API to access reactive application state inside your components (provided by the stores). Components hand over state to their managed templates, interpret (dumb) template events and publish business actions. The stores listen to published actions and update their internal state according to its logic. The changes are reactively pushed back to the components that declared their dependency on stores by accessing their data [block:image] { "images": [ { "image": [ "https://files.readme.io/ZFw80l9RRO2zMJ6MWhrm_Flux.png", "Flux.png", "1729", "768", "#715446", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Data source is reactive" } [/block] Just define a method [block:code] { "codes": [ { "code": "Space.flux.Store.extend(Todos, 'TodosStore', {\n …\n activeTodos() {\n \n return this.todos.find({ isCompleted: true });\n }\n …\n});", "language": "javascript" } ] } [/block] [block:api-header] { "type": "basic", "title": "Data source is non-reactive, but can be inferred from other state" } [/block] Add the function to the `reactiveVars` return array Reactive vars should be used for values that can be inferred by state like the current route or computed data. These won't "survive" hot-code pushes but will be rebuilt on every reload. [block:callout] { "type": "info", "title": "Example", "body": "Looking at the current route can determine the value, so after a hot-code push the value is restored." } [/block] [block:code] { "codes": [ { "code": "Space.flux.Store.extend(TodoMVC, 'TodosStore', {\n reactiveVars: function() {\n return [{\n activeFilter: this.FILTERS.ALL,\n }];\n }\n});", "language": "javascript" } ] } [/block] This will generate an `activeFilter` method on your store which can be used to get and set the reactive var. [block:api-header] { "type": "basic", "title": "Data source is non-reactive, and cannot be inferred from other state" } [/block] Add the function to the 'sessionVars' return array Session vars should be used for values that cannot be inferred by routes or loaded data and should survive hot-code pushes. [block:callout] { "type": "info", "title": "Example", "body": "Imagine a comment textarea where the user writes something. This should survive hot-code pushes and save the value!" } [/block] [block:code] { "codes": [ { "code": "Space.flux.Store.extend(TodoMVC, 'TodosStore', {\n sessionVars: function() {\n return [{\n editingTodoId: null\n }];\n }\n});", "language": "javascript" } ] } [/block]