-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making a Usable Minim #22
Comments
I think we also need to bite the bullet and write this in JavaScript vs On Thursday, March 12, 2015, Stephen Mizell notifications@github.com
|
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.. |
@zdne @fosrias Thanks to @danielgtaylor's work, it's now ES6. |
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 anarray
orobject
, we can know they are iterable because thecontent
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 callingmap
on it throws a Minim error. Forarray
elements, though, they are iterable, so the user may map over each element incontent
. 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.
The text was updated successfully, but these errors were encountered: