Maintenance? Consolidate with rnmd?

[dantman]

There are two main Material Design libraries for React Native, this and React Native Material Design. Both projects are not really maintained anymore and each miss things that exist in the other library.

Is anyone interested in attempting to consolidate the two libraries into one community maintained one; to focus the limited maintenance efforts?

[Crash--]

Why not. If someone is available to start the merge effort... ;)

[dantman]

I've started drafting a idea/proposal for what merging/basing a new library off of rnm-kit and rnmd would look like: https://gist.github.com/dantman/7dd9a78250c6a3bf6a4220afd4d75b88

It's just a shame that @xinthink isn't around to at least accept a future PR recommending whatever is created.

[wswoodruff]

@dantman That proposal looks great! When is this going to get started?

[dantman]

Depends, I wanted to double check I had community support and wouldn't be spending a bunch of time just to result in another XKCD #927 before proposing spending time on this to my employer (we're working on 2-3 RN apps all in Material Design and this situation of split communities, unmaintained libraries, and bugs makes things difficult).

[wswoodruff]

Employer backing would be even better! Yeah, I picked react-native-material-kit for my app because it had the best implementation of the material ripple, and generally looked the best. I don't have all the theming and styling structure figured out yet though. Well, you have my interest in the project anyway

[Crash--]

@dantman No worries. If a new library is created, this one will be deprecated in order of the new one. Both on github and npm ;).

Your drafting is a very good start. Some remarks:

• MKTouchable/Ripple is what that makes this lib great, looks great. The native effect is difficult to realize in pure JS. No? It has some known bugs, but you could probably fix it.
• Using props like labelStyle={} and so on can seems to be a good idea, but with complex component you can have dozens of props. I don't know if you want to be BC with the current API, but we can imagine having severals components instead.
• I don't know where Expo is currently, but last time I tried, it didn't support Native third party module. Is it still the case?

[dantman]

@Crash--

We're trying to replace two libraries with completely different APIs, ways of doing things, and legacy bugs. So I think it's fair to not care about BC.

You're right about Expo, it won't work if we need native modules. However fortunately we may not need any. The ripple in Ripple itself is not implemented in native code, it's JS. The only notable native code in this library is MKTouchable. Which as I detailed we're better off without:

• I couldn't get to work on Android
• The purpose of MKTouchable is to watch for touches without intercepting press/responder events
• However as I noted, ripples are actually not the effects of casual touches but are directly linked to the responder. You don't get a ripple when a responder isn't going to handle a press, ripples are terminated immediately when a responder is terminated (ie: you move your finger off the button), and you get a ripple immediately when a long press is triggered.
• So a native module that separates touches from press responders is pointless when we actually want ripples that are directly linked to the touchable responder.

Something else I didn't detail, Touchables aren't simple. They have fairly complex behaviour and View actually has hitSlop, ie: a region outside the View that a touch can trigger a press in. The native MKTouchable seems to bypass all this when considering touches.

[wswoodruff]

loLL hitSlop, another way of describing fat fingering. Yeah I like the idea of connecting it with touch events, and adding extra code to separate it from that doesn't seem to make much sense since it will rarely be used outside that context like @dantman just said

[dantman]

I presume that in some situations hitSlop might actually be a valid way to handle Material Design's 48dp touch target requirement.

For example the accessibility guides show dialog buttons as 36px buttons with a 48px touchable area. We could either wrap the whole button in a touchable wrapper (which I think may conflict with wanting bg/ripple of the button to be part of the touchable) or we can use hitSlop to give the button a proper 48px target. https://material.io/guidelines/usability/accessibility.html#accessibility-style

[wswoodruff]

I think having hitSlop with material components containing a ripple would be ideal, and I thought this library's buttons could use a little more padding by default, too. Dunno if that's just me tho

[dantman]

I'm working on the ripple portion of a replacement library right now and I realize that (besides the existing bugs and the flaws I already mentioned) the ripple implementation in this library is all wrong.

This library immediately starts fading in both the mask and expanding the ripple all the way to the edges at a fast pace when you touch the item.

That's not how native ripples work. When you touch the item a native ripple starts to fade the mask in slowly. Once you let go, drag your finger out of the area (terminating the responder), or a long press is triggered only then is the ripple effect triggered. The ripple itself does not reach all the way to the ends of a large element, it terminates a medium-short distance away from the ripple. And it fades out as it expands.

So the ripple implementation I'm working on is going to be a big mix of things plus custom code, making it a completely new ripple implementation:

• Touch handling will be based on react-native's Touchable* components
• rnmd-kit's Ripple will be used as a base for the mask+ripple view and ripple calculations
• I'll be fixing a bunch of the immediately obvious bugs in rnmd-kit's Ripple (such as the missing pointerEvents='none' which is needed to stop your interactions from hitting the ripple instead of content and throwing off ripple calculations)
• Ripple colors/styles will be based off the contextual material theme I've already implemented, in the end most of it may end up somewhat automatic
• I'll be redoing portions of the trigger, animation, and ripple calculation logic to implement a proper native-like ripple

[wswoodruff]

Excited!!

[wswoodruff]

@dantman I'm working with this library right now, ~are there going to be any~ how many breaking changes will there be with the library you're working on, or is there a working version of your lib?

[dantman]

@wswoodruff I haven't gotten into the components yet (Buttons, Checkboxes, etc...) aside from <Icon /> but it's an entirely new library based off both rnmd-kit and react-native-material-design, so the Api is going to be different (I'm using both libraries, react-native's api, and Material-UI as references when determining what API/props/etc to use).

However just like the existing libraries there is no conflict that stops you from depending on and requiring all 3 at once. So you will be able to do your migration incrementally by adding the new library while keeping all the code you have using -kit and migrating piece by piece.

Once I actually have a comparable set of components I'll consider creating a "Migration guide" showing how to modify existing code to work with the new library.

[dantman]

I'm still working on the library, I still need to work on components and some of the theme handling, but it has colors, shades, typography, easing, and an initial ripple implementation (may need a bit more work): https://github.com/material-native/material-native

Here's the react-native-material-design discussion: https://github.com/react-native-material-design/react-native-material-design/issues/145

[dantman]

If you don't mind working from source without documentation yet, I recommend checking out the <TextField /> (src/input/TextField.js) I've ported/implemented.

I've fixed most of the bugs with material-kit's Textfield and I've implemented a lot of missing features (e.g. error state/text, helper text, autogrowing multiline inputs, disabled inputs, dense layout, character counter, prefixes/suffixes).