Closed zephraph closed 9 years ago
Hey @zephraph! thanks! I am glad you like my coding style ;-)
Space was actually made to work in a larger system because I started creating this architecture when I realized that I need better testability for my product Prisma.
Splitting up the Meteor app into multiple packages was the first step in that direction, and Space made it really simple to express how the different parts work together. It brings a lot of benefits through dependency injection but without forcing you to tie your whole codebase to "the Space way" of writing your code.
All Space packages that you see on atmosphere are used in production, so they all have their use case. But the most prominent ones are:
space:base
is the basic plumbing for all Space modules and applicationsspace:ui
a thin layer on top of Blaze that works a bit like the Flux pattern for React.jsspace:cqrs
A minimal but complete infrastructure for using DDD (Domain Driven Design) and CQRS (Command Query Responsibility Segration) with event sourcingI totally agree with you that the current documentation is sparse and I would love to get more feedback from you as you are trying things out. Feel free to ask as many questions as you want, and we could work on an example app together – maybe the classic TodoMVC?
The Todo App was pretty much what I was thinking. It really doesn't call for multiple modules, but it'd at least show how to structure an app and the proper way to use space:ui. I'll have to look into CQRS, that's honestly the first time I've ever heard the term.
Do you create basic reusable components (simple widgets) using native blaze or do you have a better way of doing that as well?
Yeah I think for most cases space:ui
will be the only thing needed.
CQRS is a pretty big topic all by it self – and only makes sense if you have complex logic and business processes going on between several packages. It is actually extremely powerful for collaborative features where you need fine-grained control over the actions taken by every user and conflict resolution (e.g: what happens when two people edit something at the same time). However I would not recommend throwing in DDD / CQRS when its not really needed. It adds a lot of complexity and brings very specific terminology to the table that might be overkill for many apps ;-)
Reusable widgets are one area that I'd like to improve on, because at the moment I just use plain Blaze templates with params for that. It gets the job done but doesn't look beautiful.
space:ui
makes it possible to remove any app-logic from your templates so that you don't have to access your models / data from within ugly Templates.my_template.helpers
methods. In that regard it's very similar to treating templates like React.js components. You wire up specific "high-level" templates with a Space.ui.ViewController
which knows where to get your app data from and passes it on to the managed templates.
I just realized it's getting really complex to explain this stuff, it would be much easier to work on some actual code instead – I will start an example app today ;-)
Hey @zephraph I added a complete TodoMVC example to the space:ui
package:
https://github.com/CodeAdventure/space-ui
this is also very handy for future acceptance testing of the library :-)
First off I just want to say that this is seriously beautiful stuff. I've went through and looked a lot of your projects and, man, you have a knack for some seriously sexy syntax.
With the flattery aside, I'd be really interested to know how well this all works in a larger system. I noticed there's a rather large spread of space repos. Is most of the functionality contained in meteor-space and space-ui? Also, how well does this integrate with existing blaze components?
Hopefully I'll get some time soon to slap together a small application with this soon. A little more documentation and/or a more complete example wouldn't hurt though!
Anyway, cool stuff man. Keep it up!