Building blocks don’t exist.

Will a manufacture facility keep “building blocks” of its production that will last forever?

The physical Building Blocks don’t exist.

The real Building Blocks are the team and the knowledge to redo and do better.

Nothing lasts in the physical world, but knowledge gain as a team during solving real world problems will last forever.


ReForm Next is bringing three of the most wanted features:

A quick look on how it looks like:

Image for post
Image for post

The new ReForm capabilities are just a thing because we could crack the right lenses API and GADTs usage internally to allow the multi-type interface (handleChange, getStateForField, etc.). If you want read more about GADTs I highly recommend this amazing interactive article https://sketch.sh/s/yH0MJiujNSiofDWOU85loX/. …


Image for post
Image for post
A picture of pain and suffer

Android changed the security policy for HTTP communication requiring you to connect to HTTPS by default. Though it’s possible to configure your localhost to serve HTTPS, let’s do it in the easier way:

Just a reminder that this was already included in the default boilerplate of the latest React Native release so if you are starting fresh this is not necessary

If you are not using flavors

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">localhost</domain>
</domain-config>
</network-security-config>

2. Create a debug/AndroidManifest.xml with

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/><application tools:targetApi="28" tools:ignore="GoogleAppIndexingWarning" android:networkSecurityConfig="@xml/network_security_config" />…


Image for post
Image for post
Debora Cardenas (unsplash.com)

Edit: updated for JSX3 on June 5 2019

How to use ReasonML parametric types on a ReasonReact component

Suppose you have the following code (we are using genType to make our life easier here btw — we’ll post about it):


[@genType]
type state = {data: array(string)};
[@genType]
type renderItemBag = {
item: string,
index: int,
move: unit => unit,
moveEnd: unit => unit,
isActive: bool,
};
[@bs.module "react-native-draggable-flatlist"]
[@react.component]
external make:
(
~data: array(string),
~keyExtractor: string => string,
~scrollPercent: int,
~renderItem: renderItemBag => React.reactElement,
~onMoveEnd: state => unit,
array(React.element)
) =>
React.element =
"";
...Usage...<DraggableFlatList
data=[|"fubá", "corn", "cheese", "pork"|]
scrollPercent=15
renderItem=(MyItem.foo)
onMoveEnd=foo
/>

With this code you limit your users to have always “string” item type, but what if you want to give your user the ability to use any kind of item type? Parametric types to the…


Image for post
Image for post

The article presumes you are familiar a bit into ReasonML and heard about Belt. If you have any other questions leave them in the comments below!

If you are not aware about, the `option(‘a)` type is for handling values that are possibly not there. It’s like JS `null` and `undefined` but way better.

Transforming optionals

Most of the time we are handling optionals from reason-apollo responses so we’ll be dealing with JS types in ReasonML instead of records. Here, consider the type:

type user = {
.
"id": string,
"products": option(array({ . "name": string }))
};
type result = {
.
"data": option({ . "currentUser": option(user) })
"error": option(string)…


Image for post
Image for post
Here’s a demo with https://github.com/apollographql/reason-apollo along with https://github.com/callstackincubator/rebolt-navigation.

After so long, you can finally compose your Render Props in ReasonML without getting a giant nested callback hell.


Reusability is a must in React world, after mixins were considered harmful two big approaches got in to the scene: Render Props and HOCs.

Both created a lot of discussion about their limitations in the community. Render Props greatly avoid indirection but fail a bit in composability — although you can use something like Composeyou can’t still have a more explicit way to pass the props each Render Props take or not render another Render Props before you get a value from a previous one without adding some more boilerplate –and function HOCs have a great composability but fail in too much indirection. “Tradeoffs” one may say. …


Image for post
Image for post
ReForm short demo, check the source out at https://github.com/Astrocoders/reform/tree/master/demo

Forms are really complex beasts and can scale to total chaos really quickly if you don’t know how to manage all those field states and validations altogether. The nicest solution in React world is to lift the state of the form to some other component, which will take care, protect and give love to your form state.

In ReactJS there is a nice amount of solutions for dealing with form data management (Formik, Redux Forms, etc).

One of the first things I wanted to try to unleash the power of Reason’s type system was in forms, that’s why we developed ReForm. ReForm still on its early stages and certainly still there is a lot to improve from community suggestions, but we are already loving to deal with its thin API using it for both web and native worlds with React Native. …


Image for post
Image for post
The usage we are looking for

Due to the ReasonML restrictions there is no direct interop between JS HOCs to Reason. Mainly because we can’t get a bag of props and pass to the other enhanced component like we do in JS. We need to be always 100% explicit about we are doing Reason, and that is a good thing about it.

I do not want to bring up the HOCs x Children as Function x Render Prop flame war — though I admit myself being a HOC fan 😛.

Why Reason?

Me personally, I enjoy Reason and wanted to try it out in the first place because it is about of letting the Machine Do the Hard Work ™️. So I can sleep in peace at night knowing that it’s not up to me to ensure that someone will not break the application with funny things in the codebase because they did not knew X was using Y when they implemented Z and changed Y only for Z usage. If someone screws up something, Reason will certainly let you know about that. …


If you haven’t heard yet of recompose or haven’t tried yet, it’s time! It gives superpowers to stateless components in React by providing a sweet High Order Components (HoCs) API for managing states, component handlers etc. The benefits of using this approach is having a more clear separation of concerns of your component logic and getting more reusable abstraction.

Why even bother using it?

Functional Programming is all the cool guys talk about these days. Among other benefits of FP, the expressiveness of function composition and pure functions are probably my favorites. Why? Because they truly provide a way of writing uncoupled and untangled code with no implicit of functionality if used correctly (the famous question you ask time to time “from where the hell this value/method is coming from?”). Also using context (keyword this) infers implicit to the code and can behave unexpectedly. Recompose provides all of that for React stateless components. …

About

Gabriel Rubens Abreu

Developer and Head of Tech at Astrocoders

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store