Hackpads are smart collaborative documents. .
401 days ago
Unfiled. Edited by Mitar 401 days ago
What are the challenges in getting Atmosphere packages to npmjs.org and how can we solve them?  For both MDG to work out what's needed in tooling and for eventual good docs for the community package authors.

48 days ago
Unfiled. Edited by Gerardo Esteban Cordero Angulo 48 days ago
Scatter Plot - Source
Nate S Line Chart with Time Data - Source
  • 2. Base D3 Integration Pattern
We will use the bar chart example to talk about the basic pattern used to integrate D3 into a Meteor application. This same basic pattern was used for all common chart examples and should be extendable to any D3 visualization within a Meteor application.
We start by defining an empty SVG element in template markup
  • <svg id="barChart"></svg>
Not much here at all, this is really just a placeholder for D3 to do its work.
All D3 code goes in the rendered callback for the template. Some code has been omitted using ... for brevity and to more clearly illustrate the pattern.
  • Template.barChart.onRendered( function(){
Meridian W
  •     //I thought .rendered is deprecated? Correct. Updated.
Nate S
  •     //define constants, height/width
  •     ...
  •     //define scales and axes
  •     ...
  •     //define key function to bind elements to documents
  •     ...
  •     //define the SVG element by selecting the SVG via its id attribute
  •         ...
  •     //declare a Deps.autorun block
  •     Deps.autorun(function(){
  •         //perform a reactive query on the collection to get an array
  •         var dataset = Bars.find(...).fetch();
  •         //update scale domains and axises
  •         ...
  •         //select elements that correspond to documents
  •         var bars = svg.selectAll("rect")
  •             .data(dataset, key); //bind dataset to objects using key function
  •         //handle new documents via enter()
  •         bars.enter()
  •             .append("rect")
  •             ...    
  •         //handle updates to documents via transition()
  •         bars.transition()
  •             ...
  •         //handle removed documents via exit()
  •         bars.exit()
  •             ...
  •             .remove();
  •     });
  • });
Following this basic pattern allows for relatively straightforward refactoring of most D3 examples to be driven via Meteor collections. The key part is separating the D3 code into what gets run once to initiate the visual (before the Deps.autorun block) and what gets run on each collection query result change (inside the Deps.autorun block).
Andrew M
  • This seems like it will only work with very small datasets. `cursor.fetch()` deep copies all documents when it is called, so this will be extremely slow. It seems like the best approach is to create a single reactive array that is updated using `cursor.observe`, specifically using the `addedAt` and `removedAt` callbacks, which can then be repeatedly joined with `selection.data` in D3. This basically accomplishes the same effect as repeatedly calling `fetch()` without the huge CPU and memory usage of a large collection, and could be easily implemented as part of a d3 helpers package.
Nate S It is also possible to use observe instead of Deps.autorun, see alternative opalternative optionstions.
Driving Updates with Document Changes
We want our visualization to update reactively whenever there is a change in the results of the collection query, contained in the variable dataset.
  • var dataset = Bars.find(...).fetch();
  • Since we encased all of the D3 code that updates the visualization within the Deps.autorun block, we already have reactivity when the results of the query change in any way. All we have to do is make sure that the D3 visualization update code handles added, changed, and removed documents. We use D3 to accomplish this by selecting a group of elements from the SVG and binding them to a data array.
  • var bars = svg.selectAll("rect").data(dataset, key);
D3 compares the supplied data to the existing graph and computing the needed changes. Any elements that are to be newly created are returned by enter() while any elements that should be removed are returned by exit(). By using these two D3 functions coupled with an update to any documents that may have been altered, via transition(), we have all possible data changes accounted for.
Once we have the reactivity supplied by Meteor and the handling of data changes by D3, we can make simple changes to the collection documents and the graph will automatically update itself. Since the visualization code is reactively driven by the collection documents, the source of the data change is not relevant. The changes can be made via event handlers, as shown below, or by any other mechanism.
  • //basic insert/update/remove operations on the collection cause a reactive update to the visualization
  • Template.barChart.events({
  •     'click #add':function(){
  •         Bars.insert({
  •             value:Math.floor(Math.random() * 25)
  •         });
  •     },
82 days ago
Unfiled. Edited by Asif Rahman 82 days ago
  • meteor add natestrauser:filepicker-plus
151 days ago
Unfiled. Edited by Bhumu Kathiriya , bhumi kathiriya 151 days ago
Bhumu K jnjnjhnnmnjkmkm
bhumi k This pad text is syn
no thate viewing 
es the same tlk;
ext.   on d
196 days ago
4 / 11
Unfiled. Edited by Laurie 196 days ago
  • Persist database across container restarts
  • Formatting of Pad List
  • Sign Out Button formatting
  • Deemphasized languages selector
  • Fork on non-code changes
  • Spinner on container starts
(How exciting!!!)
Laurie ggggg
221 days ago
Unfiled. Edited by Tomas Hayes 221 days ago
James G
  • ViewModel doesn't play nice with models returned from collections. ViewModel is good for like a web form that only sends an email. If you are rendering models, perhaps to update them, you actually create more work for yourself by using ViewModel than by using your models with AutoForm. The reason is you get the data out of the form via 2 way binding, but it's only in the state of the ViewModel component. Now you still gotta pass it to your actual model. ViewModel is overhyped. It's only good for the simplest least dynamic of use cases. Any time you use real models from the database you need a slightly lower level of abstraction, but if used properly (i.e. as just described) you actually have a lot less work than if you used ViewModel.
Tomas H
  • I've been using blaze with manuel:viewmodels. Can't conceive using blaze in other way now. Love it!
277 days ago
Unfiled. Edited by Kehinde Orilogbon 277 days ago
Timer is a moments helper package that allows for quick usage and manipulation of time and dates in your application. You don't have to spend time writer UI helpers for times and dates for your application. 
287 days ago
4 / 4
Unfiled. Edited by raza 2022 287 days ago
raza 2 Stack OverFlow
  • Setup unit testing 
  • Create Add Part functionality
  • Add hackpad link to README
  • Setup docs using swagge

Contact Support

Please check out our How-to Guide and FAQ first to see if your question is already answered! :)

If you have a feature request, please add it to this pad. Thanks!

Log in