search

meteor-space / ui

Pattern-agnostic base UI package to gain control over your Meteor UI
MIT License
121 stars 15 forks source link

Integrate into Orion #30

Closed gam-ragnar closed 9 years ago

gam-ragnar commented 9 years ago

Love this project how do we make this work with Orion https://github.com/orionjs/orion ?

DominikGuzei commented 9 years ago

Wow, sorry for the late answer @timfam – somehow your issue went under my radar! Do you want to rewrite the frontend of the Orion framework to use space-ui?

gam-ragnar commented 9 years ago

Hey @DominikGuzei I'm considering the best way to introduce flux Orion or maybe redux https://github.com/gaearon/redux to Orion users. I have looked at your implementation and that of https://atmospherejs.com/huaming/flux-store and https://atmospherejs.com/meteorflux/dispatcher. A comparison will be great from you or any other maintainers on similarities and differences. What are your thoughts on the issue raised be redux and are you open to space-ui being ported to js? Js is easier for majority of meteor devs, personally i prefer coffee but now provide a compiled js as default.

DominikGuzei commented 9 years ago

Ok, do you intend to switch to React as the view layer? Because I haven't found the time yet to publish a react mixin for space-ui, although it should be pretty simple.

I don't know most of the other packages and to be honest, although space-ui was inspired by react/flux it is much closer to Meteor and basically only steals the concept of stores and event-driven systems which i really like. You can read through the source in 1-2 hours and there are not big surprises, mostly syntactic sugar and niceties.

However there are some differences between the various React/Flux store/dispatcher implementations and those that you find in space-ui. For starters, in Meteor you don't need to "wait" on other stores because everything is reactive, so you just listen to data changes from a store and do something with it. Also the artificial limitation of the Facebook dispatcher to allow only one event to be published per run-loop felt really strange and provided no obvious benefits.

FYI space-ui is also based on space:messaging where a lot of interesting parts are actually coming from. There you get for example the Space.messaging.EventBus to send events between components on the client, or on the server. Take a look at the (just) updated TodoMVC example which shows most of the concepts.

So to sum it up, in some parts space-ui is much simpler than most of the other frameworks and in others it's more Meteor specific and wouldn't work as a standalone Javascript framework.

gam-ragnar commented 9 years ago

Nope, not switching to React personally still digesting famous.org and famous-views (I digress). You answered my next question about the dispatcher limit :). We still have the issue of coffee/js and I think I should ask what are your goals for this project - make it a framework or just a group of packages that works together. The goal of Orion to get the best packages together to make Meteor ready and usable for enterprise (long journey I know but we have to start somewhere)

DominikGuzei commented 9 years ago

This package is the frontend framework for all of my Meteor applications and a few other startups I know and work with. It is part of multiple packages working together (space:base, space:messaging and sometimes (for bigger business apps) space:cqrs) to provide opinionated conventions how to build Meteor applications. In that regard i would see it in a similar role like Backbone / Angular which also provide basic conventions to take some burden from you. But fullstack, of course – as Meteor.

So I see it as a architectural framework that evolved out of my own applications and especially out of the need for structural conventions, fine-grained control, event-driven systems and ease of testing.

Where do you see the real benefit of switching to Javascript instead of Coffeescript? Most people never contribute to open source projects anyway. And honestly, I don't want to work with people that hate Coffeescript just because "they don't understand it" – i mean seriously? They should get another job. Don't get me wrong, I love Javascript and have been writing it over the last 10 years. It's not that I come from Ruby or Python and try to avoid the basics. CS is just Javascript but with a much, much simpler syntax that reads well and enables interesting meta-programming capabilities. Additionally Meteor made it so ridiculously easy to use Coffeescript (without any drawbacks) that for me the normal arguments against it (extra effort, compilation steps, …) are moot IMO.

gam-ragnar commented 9 years ago

I like the space concept (settled). While I agree with most of your points on coffee(preaching to the choir here) Js helps to on-board new devs and ensures a project is used by all. Most will not contribute in meaningful way but some will and help make space the standard. ES6 will eventually force many of coffee concepts on JS in the interval we have to deal with crowd.

I will use space on my next project after that I will see what I can do about finding a way to get the js guys to either bite the bullet and learn coffee or will may provide a js version. One thing is for sure meteor needs a spacey-kinda concept

DominikGuzei commented 9 years ago

Yeah, try it out on your next project and feel free to ask any question on the way! I know that a lot of parts need better documentation, maybe you can help me there in the first step :wink:

One of the things that I hate about ES6 is that it does not support calling static methods in the class declaration. This basically eliminates 1/2 of the sweetness of the space framework because I use that heavily in my applications. Others like @Sanjo started porting these things to ES6 annotations, so that you can still keep the meta-programming sugar.

D1no commented 9 years ago

tldr: +1 non-coffee implementation / code-samples Hey, just my 5 cents as I came by because of some enterprise needs for first start componentization. After first assessment, have to agree with timfam. Beside being a dope in CoffeeScript; I'd need a day to get the syntax down before understanding the (space) library - which depends largely on practice with cs.

So I agree. CS is very very nice for mvps and single developer action but, as mentioned, not for on boarding devs and maintainability. Many projects try to stick to strict node.js/meteor stack principles (pure JavaScript mantra) sometimes even the platform specific style guides and rule out divergents early.

We personally stick to ES6 and lately transitioned to TypeScript. A super-set of ES6 JavaScript with added functionality, code and declaration separation and type checking. Also with access to static methods from classes if you would like to try it out ;)

That being said, very impressive framework but I personally would need to compile it all down to JavaScript and try to understand the generated code. For most people is vanilla JavaScript simply the proficient baseline - packages with already non-standard code samples are than a pain. Maybe you are unnecessarily limiting yourself and audience but I can see why you love CS :)

DominikGuzei commented 9 years ago

Ok guys, let's do it – I guess Javascript devs are too stubborn and I can't stand another "i can't read that, it's not my language" discussion.

I will rewrite the whole thing in Javascript and add a non-static API that will be better compatible with ES6 classes to map event/command handlers. Maybe you can try the framework and we can formulate the API together, so that both parties are happy can use the best aspects of their dialects.

gam-ragnar commented 9 years ago

This is great news! I just invited you to gitter-im for a quick chat on how best to move forward

gam-ragnar commented 9 years ago

@DominikGuzei been waiting on you so we can get started on super example others can contribute to.

DominikGuzei commented 9 years ago

Hey @timfam and @D1no, just wanted to tell you that i started working on a small business app example that @timfam and i talked about. I am also writing it in pure Javascript to get a feeling of the current API without using Coffeescript :wink: Already found a lot of potential for improvements and will update the packages on the fly when things stabilize.

If you like to follow the progress, you can checkout the repo of the first app: https://github.com/SpaceJs/cqrs-shop-example

You have to symlink the latest Github versions of space:base and space:messaging into the packages folder :wink: this requirement will go away when the new APIs / features are published to atmosphere.