Making a Usable Minim

[smizell]

I'm on User Support, so I have a little time to type this out. I've mostly been away from the computer this week, which has been nice :)

I wanted to write out some thoughts that I have to get Minim to a usable state. Minim started out as a POC for interacting with Refract elements. Now all the sudden it's something that we may like to use, so it will be good to give it some added care.

First, I think the most important thing here is to get the API right, and I don't think it's quite there yet. Currently, to create a new type object, you have to extend one of the primitive type classes, and this is not good for several reasons. I believe "classes" only exist in CoffeeScript and ES6, and I don't think they are interoperable at this point (maybe?).

To get it right, I think we need to have one element object that handles certain categories of elements that can be easily wrapped to create new element types and functionality (like ArrayElement.createClass, much like React and Backbone). This base class can introspect the content to see what methods should be made available to the user. This means we don't have to care if an element is an array or object, we can know they are iterable because the content of the element is iterable.

To think of an example, a string element is a value-like element, but it is not iterable. This means calling map on it throws a Minim error. For array elements, though, they are iterable, so the user may map over each element in content. This all saves us from having element explosion while encapsulating all functionality in one "class."

Next, we need to define all base elements from Refract (once we finalize the first iteration of it, which we are hopefully close). This is important for Minim to interact with new element types. With the previous recommendation above, I believe this will allow for working with any Refract document without having to pull in namespaces. This will be a big win I think, and may save us from needing to have a factory for registering elements.

Next, I believe we need to work to remove lodash as a dependency. I like using it to get up and running quickly, but if this is going to be used in a browser, there is no need to load another library for simply things. This is not a hard requirement in my mind, but could be beneficial.

Lastly and related, to bring this all together, this needs to be ran through Browserify to make it usable in the browser. At that point, it should be a very small and usable library for interacting with Refract payloads.

Doing all of this gets Minim to a usable state in my mind, and we are not far from this at all. In light of this, I vote that we close #21 for now to focus on these other things, as error handling will be much easier with a central class. I would then like to do a refactor on how the elements class are organized to greatly simply the code, making it easier for Minim to simply interact with a document that introduces any kind of element.

[smizell]

cc: @fosrias @zdne

[fosrias]

I think we also need to bite the bullet and write this in JavaScript vs
coffeescript

On Thursday, March 12, 2015, Stephen Mizell notifications@github.com
wrote:

I'm on User Support, so I have a little time to type this out. I've mostly
been away from the computer this week, which has been nice :)

I wanted to write out some thoughts that I have to get Minim to a usable
state. Minim started out as a POC for interacting with Refract elements.
Now all the sudden it's something that we may like to use, so it will be
good to give it some added care.

First, I think the most important thing here is to get the API right, and
I don't think it's quite there yet. Currently, to create a new type object,
you have to extend one of the primitive type classes, and this is not good
for several reasons. I believe "classes" only exist in CoffeeScript and
ES6, and I don't think they are interoperable at this point (maybe?).

To get it right, I think we need to have one element object that handles
certain categories of elements that can be easily wrapped to create new
element types and functionality (like ArrayElement.createClass, much like
React and Backbone). This base class can introspect the content to see what
methods should be made available to the user. This means we don't have to
care if an element is an array or object, we can know they are iterable
because the content of the element is iterable.

To think of an example, a string element is a value-like element, but it
is not iterable. This means calling map on it throws a Minim error. For
array elements, though, they are iterable, so the user may map over each
element in content. This all saves us from having element explosion while
encapsulating all functionality in one "class."

Next, we need to define all base elements from Refract (once we finalize
the first iteration of it, which we are hopefully close). This is important
for Minim to interact with new element types. With the previous
recommendation above, I believe this will allow for working with any
Refract document without having to pull in namespaces. This will be a big
win I think, and may save us from needing to have a factory for registering
elements.

Next, I believe we need to work to remove lodash as a dependency. I like
using it to get up and running quickly, but if this is going to be used in
a browser, there is no need to load another library for simply things. This
is not a hard requirement in my mind, but could be beneficial.

Lastly and related, to bring this all together, this needs to be ran
through Browserify to make it usable in the browser. At that point, it
should be a very small and usable library for interacting with Refract
payloads.

Doing all of this gets Minim to a usable state in my mind, and we are not
far from this at all. In light of this, I vote that we close #21
#21 for now to focus on these
other things, as error handling will be much easier with a central class. I
would then like to do a refactor on how the elements class are organized to
greatly simply the code, making it easier for Minim to simply interact with
a document that introduces any kind of element.

—
Reply to this email directly or view it on GitHub
#22.

[zdne]

Good thoughts! Browser version is indeed much needed (this also applies to Fury). I second @fosrias in that we should probably rewrite this to ES6..

[smizell]

@zdne @fosrias Thanks to @danielgtaylor's work, it's now ES6.