meteor-mantra-kickstarter
meteor-mantra-kickstarter copied to clipboard
mantrajs
Why Astronomy?
What is role of Astronomy Classes in Mantra? It seems limited to defining a schema for validation. Where were are the classes and methods invoked (e.g. Actions, Containers, Components etc.).
Astronomy is a mechanic for defining validatable schemas for the Mongo collections used by the rest of the app, as well as a more normalized means of accessing that information. It exists as a separate system that will work in tandem with the rest of Mantra, as a means of data acquisition to be placed into containers.
I looked through the repo and other then defining a schema (object), I could not find where astronomy classes (e.g., user = new User()) were evoked. From what I understand, containers subscribe to publications and mutations are handled via actions. form validations are defined directly inside stateless components. It seems that Astronomy invites the potential for side-affects. For Blaze, I understand but I'm not sure I see the same sort of alignment in the React-Mantra or the React-Redux world.
There's some poorly documented magic happening with Astronomy that isn't really apparent. For example, you don't actually ever need to do a new User(), in order to get an astronomy class. You can still insert and retrieve from the database as you see fit, but Astronomy actually taps into the collection itself to make sure that returned queries from collections are always Astronomy classes anyways.
I haven't dug into this project enough yet to really assess how much of Astronomy is being practically used, but it's safe to say that if the classes are defined, and assigned to a collection, the features are there.
@natecox Like @smooJitter, I'm trying to figure out how to fit Astronomy into a Mantra project, and I looked to this repo for guidance too. Astro models are defined in the lib directory, but those files are not imported anywhere. It was commented out in the methods files. Looks like work-in-progress to me.
@dtwist I'm not 100% certain, and I will test this later, but I believe that because the Astro class isn't being defined in an imports/ directory the file is still being parsed, Astronomy is engaged by the class definition and is modifying the two collections to return an astro class on query by default.
The big caveat here is that even if it were, you can still pretty much use a returned item just like a normal Mongo returned item because it's essentially a superset.
@dtwist it's true it was WIP at a time. The Astro classes were put into the lib folder.
Guys, there is a v2 https://github.com/jagi/meteor-astronomy/tree/v2 which which I have not had a chance to test yet. Let's keep this issue open for now
Shouldn't Astronomy be moved to the roadmap in the Readme.md then? I have been trying to get Astronomy to work using the current collection examples, but it simply seems to not be evaluated.
Also see this issue.
Again, it appears Astronomy may loose a bit of its luster here. V2 looks fantastic but in the context of mantra there's not much us to updating collection attributes via client-side object models. Mantra essential has components, containers, actions, and perhaps method_stubs. Correct me if I'm mistaken, but I only see the potential value in action files. If Components used Astro classes to mutate collection attributes, we risk side affects plus it limits the role of both container (component state and props composed) and action (were collection and state mutation are called) files. Just a few thoughts. I appreciate this repo but astronomy models seems incompatible, v2 won't solve that. I could be very wrong, I like to know that I am because I've been looking forward to using the astronomy.
@smooJitter et al, I think you may be right. What would be viable alternatives for this kickstarter? (My primary concerns would be client and server side validation).
+1 on @sandervanhooft question. I wonder what place should have Astronomy in a mantra app, and what should be the good practice for validation.
Have a look at the topic I just posted on meteor forums, similar questions.
I think it's important to note that Astronomy works on the server also. Astronomy simplifies collection hooks, collection helpers, etc.
The Meteor Mantra Kickstarter works with Astronomy 1.2. I have just now committed a clean-up and upgrade of Astronomy to v2.1.0 to my kickstarter fork.
I am trying to keep my fork as close as possible to the intent and spirit of the original, while upgrading all Meteor and Npm packages to their latest versions.
Astronomy seems brilliant. Version 2.1 makes it almost 100% transparent. It allows you to add validations and event driven transformations to your collections in a very natural way.
Forgive my ignorance, I'm still learning. By integrating GraphQL into Mantra, doesn't that eliminate the need for Astronomy?
