{"_id":"5625ca89d0f87e190014c4d3","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"},"__v":17,"user":"5600910981a9670d006d144f","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"},"project":"56000f0d8c0c9d0d00dcad21","githubsync":"","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-10-20T05:00:57.499Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"Meteor is a great platform for building real-time apps with Javascript, but for bigger applications the lack of conventions and UI architecture can become a real problem. Templating in Meteor is nice but lacks a lot of architectural patterns. When using the standard templates / managers logic starts to be spread all over the view layer, where it becomes hard to manage.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"space:ui\"\n}\n[/block]\nFoundation package provides a pattern-agnostic set of tools.\n\nSee the [API documentation](https://github.com/meteor-space/ui/blob/master/README.md)\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"space:flux\"\n}\n[/block]\nCoupled with `space:ui` for application foundation and `space:messaging` to handle events published from components, `Space.flux.Store` completes the picture for implementing Flux in Meteor. Reactivity allows `Space.flux.Store`s to simply expose a reactive API rather than emitting a 'change event' like in other flux architectures. \n\nHere's an example:\n[Todos.TodosStore](https://github.com/meteor-space/todos/blob/develop/packages/app/source/client/stores/todos-store.js)\n\n[What's Flux?](doc:flux)\nSee the [API documentation](https://github.com/meteor-space/flux/blob/develop/README.md)\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Messaging to decouple layers in your UI\"\n}\n[/block]\nUsing messaging between the various layers of your application is an\neffective way to decouple them, this is where `space:messaging` steps in to provide the infrastructure. We can demonstrate this by explaining each part of a flux design:\n\n## Stores\n- Depend other reactive data sources, such as a Meteor.Collection or other Store\n- Subscribe to events published on the Event Bus\n\n## Controllers\n- Subscribe to UI events\n- Interact with UI Singletons, such as the router\n- Send Commands to the `Space.messaging.Api` (a wrapped Meteor.method)\n\n## Components\n- Depend on Stores for state\n- Provide an API to their managed templates.\n- Publish UI events\n\n## Templates\n- Display given data\n\nEach layer plays an important role and the implementation details can be changed easily.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"View Integrations\"\n}\n[/block]\nhttps://github.com/peerlibrary/meteor-blaze-components\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"What about x?\",\n  \"body\": \"Currently we only integrate with Blaze Components, but the architecture is designed to be decoupled to allow for other drivers to be written\"\n}\n[/block]","excerpt":"","slug":"user-interface-overview","type":"basic","title":"User Interface Overview"}

User Interface Overview


Meteor is a great platform for building real-time apps with Javascript, but for bigger applications the lack of conventions and UI architecture can become a real problem. Templating in Meteor is nice but lacks a lot of architectural patterns. When using the standard templates / managers logic starts to be spread all over the view layer, where it becomes hard to manage. [block:api-header] { "type": "basic", "title": "space:ui" } [/block] Foundation package provides a pattern-agnostic set of tools. See the [API documentation](https://github.com/meteor-space/ui/blob/master/README.md) [block:api-header] { "type": "basic", "title": "space:flux" } [/block] Coupled with `space:ui` for application foundation and `space:messaging` to handle events published from components, `Space.flux.Store` completes the picture for implementing Flux in Meteor. Reactivity allows `Space.flux.Store`s to simply expose a reactive API rather than emitting a 'change event' like in other flux architectures. Here's an example: [Todos.TodosStore](https://github.com/meteor-space/todos/blob/develop/packages/app/source/client/stores/todos-store.js) [What's Flux?](doc:flux) See the [API documentation](https://github.com/meteor-space/flux/blob/develop/README.md) [block:api-header] { "type": "basic", "title": "Messaging to decouple layers in your UI" } [/block] Using messaging between the various layers of your application is an effective way to decouple them, this is where `space:messaging` steps in to provide the infrastructure. We can demonstrate this by explaining each part of a flux design: ## Stores - Depend other reactive data sources, such as a Meteor.Collection or other Store - Subscribe to events published on the Event Bus ## Controllers - Subscribe to UI events - Interact with UI Singletons, such as the router - Send Commands to the `Space.messaging.Api` (a wrapped Meteor.method) ## Components - Depend on Stores for state - Provide an API to their managed templates. - Publish UI events ## Templates - Display given data Each layer plays an important role and the implementation details can be changed easily. [block:api-header] { "type": "basic", "title": "View Integrations" } [/block] https://github.com/peerlibrary/meteor-blaze-components [block:callout] { "type": "info", "title": "What about x?", "body": "Currently we only integrate with Blaze Components, but the architecture is designed to be decoupled to allow for other drivers to be written" } [/block]