re-mdl
re-mdl copied to clipboard
Discussion
First I'd like to say thanks for this project. It is exactly what I was looking for and I was just about to write this myself!
This is in no way intended to be an official merge request. I just wanted to start a discussion.
-
Since it is such a lightweight wrapper around mdl, I don't see any real reason why this couldn't be production ready with just some additional documentation. One of my commits includes the beginning of codox.
-
After using
material-ui
, re-mdl seems pretty clunk to create seemingly normal components. For example, most of my buttons tend to be something like:
[mdl/button
:raised? true
:primary? true
:ripple-effect? true
:label "Next"
:on-click #(common/swap-tabs! :security)]
I think it would be nice to add utility methods that provide variations of certain components. For example, see the icon-badge
, flat-button
, raised-button
, and floating-action-button
. I also think it makes it easier to read the intentions of your code:
[mdl/raised-button
:primary? true
:label "Next"
:on-click #(common/swap-tabs! :security)]
- This may also clean things up a bit... For example, it may be nice to change the signature of
badge
to:
(defn badge
[badge-label & {:keys [el id class attr
no-background? overlap? icon?
child]
:or {el :span}}])
The normal use case would be if you want to use a badge, you probably want something in the label. I'd rather people have to explicitly pass nil rather than that be the default. Likewise with text based buttons, icon buttons, etc (you should have to provide the button text or the icon). For example, this could clean up the raised-button
even further:
[mdl/raised-button "Next"
:primary? true
:on-click #(common/swap-tabs! :security)]
I would argue the above is clean and clear to the reader what it's doing.
- I also realize this project is to provide just a lightweight wrapper around MDL, but it may be nice to think about adding an
extras
/experimental
namespace of some kind to provide useful features not yet available in MDL. For example, two things I need are Dialogs and better validation of input fields. I realize this is likely out of the scope of this project, but it would definitely help people make more production ready apps. For dialogs I'm basically using this.
Oh, we should also make sure that all handler-fn
params have defaults. This was causing errors in the console trying to call a nil function (i.e. see textfield*
).
@vincentjames501 Thank you so much for this! Taking some time to go through it now. Some first flush responses without looking at code:
- Emphatic agreement. Docs are a must.
- I agree on the clunk. I think utility methods are an elegant solution, as they still allow clunk when you want it. Another possible route to decrease clunk (which could happily coexist with utility methods) is a key that takes a vector of class keywords.
- I think the reason
badge
came together in an odd way was my accommodation of icon badges, which require another element inside. Separate util fns could handle that nicely though. - Absolutely, and this has been something I've been wanting to do. Dialogs/snackbars are going to need some thoughtful cljs wrapping anyway, and there's stuff like collections that could use some react conveniences. If we want to get really fancy, using react's CSSTransitionGroup stuff with some of mdl's css animation would be neat too.
I'll pour though this stuff today, and should have more to add to the discussion later. I also invite @canweriotnow and @meatcompute from my team to take a look and chime in if they like.