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.

space:ui

Foundation package provides a pattern-agnostic set of tools.

See the API documentation

space:flux

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.Stores to simply expose a reactive API rather than emitting a 'change event' like in other flux architectures.

Here's an example:
Todos.TodosStore

What's Flux?
See the API documentation

Messaging to decouple layers in your UI

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.

View Integrations

https://github.com/peerlibrary/meteor-blaze-components

📘

What about x?

Currently we only integrate with Blaze Components, but the architecture is designed to be decoupled to allow for other drivers to be written