Suggestion: Drop term "collection" in favor of "object"

Makerhood
1

I’m new to Make (really liking it so far!) so please consider this as constructive feedback.

In first getting acquainted with the platform I was confused with the difference between references to “collection” and “array”. I get it now but for sake of clarity I’d like to suggest that the term “collection” be dropped in favor of “object” in the product.

In tools I’ve worked with “collection” is often synonymous with “array”, so seeing these terms refer to very different things tripped me up. A structure representing key:value pairs (flat or nested) is more often referred to as an “object” than a “collection”. And, in several areas of the documentation “collection” and “object” are used interchangeably. I believe it will be clearer for those new to the platform if “object” is adopted throughout.

Thoughts?

Thank you,
John

2

I have to vote against this. Collection is used all over the place in make UI and docs. It’s not that confusing actually.

And a collection is an associative array and a full feature of ES6 called a “map”.

Many of the functions we use in arrays are actually collection functions from JavaScript built for ES6 like get().

The thing I would agree is to figure out where object is actually used objects exist only in the sense you use object notation to access elements of output and input bundles.

1 Like
3

Extending on this,

Even as a coder since I was a child, I actually find in makes context collection makes more sense.

In terms of training non-technical people/creatives/designers on using make. a list of collections is a bit easier to explain.

The Document/Collection model is also the way make datastores work(mostly). the fact that they call them collections in scenario flow actually helped me draw the lines to eventually understanding how to optimize make datastores from an operations cost viewpoint. which was hard for me coming from a MySQL (relational database) background.

Bias Admission: i also want the make team to have the opportunity to finish the existing documentation before sidetracking into refinement.

1 Like
4

Make has a huge challenge here trying to keep make a no code tool. In fact it is locode if you want to be more exact. To use make requires you to understand the intricacies of manipulating data structures like strings, object, arrays and collections.

If you don’t care to understand these, Zapier is a much better solution albeit a lot less powerful.

It is exactly in this area that make documentation is not only lacking but serves to confuse too.

1 Like
5

Thanks @alex.newpath and @JugaadiTech for your input. It’s very helpful to get thoughts from folks who are more experienced with the platform than I am. I won’t quibble over this - it was just something I noticed early-on and thought I’d put it out there as maybe something to think about.

6

Just to clarify - there is no such thing as a type Collection (big C) in JS. It’s a generic term for several types including Map, Set, Array. I only mention this because Make’s adoption of the term Collection to represent a specific one of these (map) is precisely what initially tripped me up.

7

I’ve been using make for 6 years and I agree that this is quite confusing, especially as there is virtually no documentation on what the terms mean.

In a low code platforms, often terms are used in ways other than their strict technical meaning, also sometimes “easy” euphemisms are used.

At the very least defining what these mean would be great.
Finally creating some content around them would be even better.

8

Collections are really just key value pairs of data. Simple as that. And you’re right the Make Glossary mentions collection once and does not define collection.

The definition of bundle is also quite incomplete in the Glossary. A bundle is simply a collection coming out of an output from a module. Bundles drive the number of times a subsequent module is executed.

The idea of converting bundles to arrays with aggregators is not very well understood but is potentially a huge operations saving exercise in terms of how scenarios are designed and built.

The Parse JSON doc defines the difference quite clearly between a collection and an array. The Parse JSON is a deceptively misnamed module – it can be used to generate sample data with a data structure defined or from scratch to test scenario fragments and data manipulation of all sorts.

I like to think of all of this in relation to a table of data in a spreadsheet which many people understand. I think creating a diagram of the relationship between data types, collections and bundles and all the ways they can be structure and manipulated would be a very useful help doc.

  • A data type is just string, number, boolean, date or array and they type the values that go into collections

"Peter" is a string, 1 is a number, true is a boolean, 2012-12-01T00:00:00Z is a date and [1,2,"a"] is an array.

Arrays can have nested arrays too.

  • A collection is one or more cells of data (the row/col identifier being the key, and contents of cell being the value). A value of a collection can be an array as well which can nest more collections.

{ "name" : "Peter", "ID" : 1, "MyArray": [1,2,"a"]}

  • A bundle is zero or more rows of data in the spreadsheet composed of one or more collections. A bundle is actually an array itself where each element is a collection!
[
{ "name" : "Peter", "ID" : 1, "MyArray": [1,2,"a"]},
{ "name" : "Mike", "ID" : 2 }
]

Here are 2 bundles that can be outputs from a module. All subsequent modules will execute 2 bundles and without any previous path filter will use 2 operations.