You need to expose your collection.
Exposure creates a method and a publication depending on the options. This needs to be included and run server-side.
Then you need to query the users.
const query = Users.createQuery({profile: 1}) // or Meteor.users depending on how you import/export
query.subscribe()
Listen, thatâs exactly the problem with the files being all over the place - I cannot make heads or tails of what goes where and why.
Isnât there some kind of step-by-step walkthrough which explains exactly how to
a) create a collection
b) secure it on the server-side
c) subscribe to it on the client-side
d) and finally query it?
Because frankly Iâm a bit tired of having to search through all the files to see what gets defined where and why and how itâs imported there and back again and three days from sunday.
For instance, I just tried to create a namedQuery on the server in order to expose it just like in your boilerplate only to have the build system tell me:
Error: We could not find any collection by the name SampleCollection
meteor mongo tells me that this collection does exist and that it also does have sample data.
I concur, for someone so feverishly complaining about MDGâs lack of simplicity and clarity in their documentation, youâre doing a bangup job muddying your own waters.
I am now complaining about the lack of simplicity in grapher also Based on feedback itâs confirmed that it is not that simple. Please come-up with solution to make it better, or state directly what makes it harder for you, so I can have at least some idea of whatâs so hard to understand. Otherwise itâs just called âwhiningâ
Ok, the reason for âTasksâ not existing is because the collection needs to be loaded and registered as Mongo.Collection. Bc the query tries to search a âTasksâ collection and if it doesnât find it breaks.
Better error "We could not find a collection by the name âtasksâ, make sure you imported it before creating the namedQuery
So we need to specify the loading orders:
What we can do is what we did for createQuery, like Tasks.createNamedQuery(âallTasksâ, {title: 1}, I remember I had a very good reason why I did not do it so. But will investigate.
Links should be loaded separately from collections. The reason they are not put in the same file is because you can have Users -> Comments link and Comments -> Users inversed link. Interdependency loop, and makes the âCollectionâ look like { __esModule: ⌠}, and we need the real one when adding links.
Cheers man. Very good feedback.
We should have a âGet startedâ guide in the docs section explaining this. Iâll be working soon on this.
The obvious solution to the Interdependency loop problem is to have collections looked up by name. You already need this when collections are referenced as keys. Also it makes it easier to generate links dynamically from data.
I have updated the README.md (Added current architecture + description)
I made some small changes to the structure to make it more clear
I commented out everything in grapher to describe it in depth.
@gunn I truly appreciate your solution, thing is that was how it was first thought put a String instead of a Collection object. And lazy-load later on. However, we wanted to avoid that because it violates the modular approach principles. This is how we actually did it in âQuantum Frameworkâ when in Meteor 1.2.
Dynamic Links ? Thatâs one bad-ass concept. Iâve yet to see the aplicability of it, but it sounds very cool! If the community will want this, weâll think of a way. Until then, we keep it like this, for the sake of explicity.
The main reason we allowed stuff like:
createQuery({
users: { firstname: 1}
})
Is to allow testing using Grapher Live. But we found out itâs pretty catchy and we should also allow it like this, but see what @rhywden encountered ? The exact thing we were afraid of, âno collection foundâ, because collection was not loaded, so query could not be created.
We turned this problem on multiple sides, and unfortunatelly, thatâs the best way to do it :), itâs not that big of a problem, because you still keep âlinks.jsâ near the collection, so concerns are properly separated, itâs just that the loading order differs.
There are at least 5 other reasons of why collections should exist as objects when links are created, itâs related to data consistency and âautoremoveâ.
If you subscribe to a query, it will morph into a reactive query meaning you can just do fetch(), however, if you use createQueryContainer (from grapher-react), you have the ability to specify {reactive: true} or {reactive: false}
Thanks so far with the feedback guys, youâve been really helpful. And thank you for the encouragements, got a bit of an ego-boost.
new Promise('I will create a grapher video tutorial explaining everything from zero to advanced')
OFF TOPIC:
Right now my focus is on Meteor Tutorials, get the first chapter going, create the laracasts for Meteor and create hysteria for Meteor again. A lot of people last year quit Meteor before introducing modular approach and integration with React. Which together with Grapher (ofcourse), and Flow Type (maybe) finally makes it ready for the large scale.
We lost some good guys along the way. Our plan is get them back, and bring new guys in as well. Idea is to make them realize that this platform is trully great.
ON TOPIC:
After analyzing our business requirements in depth we realized we need 2 more things to grapher:
The conditional reactivity graph⌠oh boy I have no idea how to even begin thinking about it. I left an API candidate there. Thing is, by experience I realized that everything is possible when you are programming, but first you need to get the API right first, the âwhatâ, then think about the âhowâ.
Because tutorial videos only really make sense for stuff that you need to visualize - like movements in the three-dimensional space or propagation of waves or relationships between models.
But programming is based on text. Itâs a bad candidate for visualization. I know that itâs terribly en vogue right now to make videos left and right but in my opinion as a teacher you have to think about why youâre using the medium youâre using. And whether itâs actually a good fit for what you want to show.
With a text-based tutorial, you can easily âpauseâ, you can easily skip forward and you can just as easily go back in case you missed something.
Thatâs not something you can do with videos - I know that Iâm always frustrated by questions like: âSo, where did he explain that concept?â or âWhat was the syntax he used again?â
Hell, with plain text I can even use the Search feature of browsers to search for keywords I remember on the page. I can copy&paste easily.
And so on and so forth. Again, I have nothing against videos in general. I just think they make a poor fit for explaining programming concepts of a framework. Explaining sorting algorithms? Fine. Explaining how IoC works? Also fine. But coding? Nope.
I really thought you were just trolling, but you raised some very enlightning arguments.
The thing is I personally learn code by checking text, the âHTMLâ tutorial can still have vizualizations & images, it can have a very nice table of contents that you can access, and you can easily skip some parts you already know, you can come back later to it, without having to âskip the video to where you left ofâ. You can copy paste chunks of code, you can search keywords. You can pause scrolling to digest what was saidâŚ
Holly sh**. You can improve the tutorial without having to reshoot the video.
I mean you can make it fun & engaging via what HTML & JS has to offer⌠However some people would prefer video tutorials bc they are more personal, but this only applies to very charismatic people, with my eastern european russian-like accent I doubt charisma is my strongest suit.
Too bad I kinda promised the community Video Tutorials on Meteor, but I believe as long as I find a nice innovative and super friendly way to deliver these tutorials they may forgive me, as long as I do a freaking good job.
I did not make a descision yet, Iâve yet to ponder on it. But, heck, youâre right.