A while ago I published this article about building an accessible and reusable modal/dialog component in React.
The component achieves the following requirements:
- A reusable component API: we should be able to easily use our accessible modal anywhere and populate it with content.
- Accessible markup.
- We should be able to open & close the modal just using the keyboard.
- Trap the focus in the modal: since the modal is an inert component, the keyboard navigation should be trapped inside of it once it’s open.
The component makes use of React features like the Context, Portals, and Ref. To evaluate whether ReasonReact is ready for production, I will build the same modal in Reason and report what I like/dislike.
I will be doing that once again in iterations. You can find the final source code here. There is a separate branch for each iteration.
Iteration #1: the modal as a simple div
The modal component
First, let's create the modal component:
/* src/Modal.re */
[%bs.raw {|require('./Modal.css')|}];
[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";
[@react.component]
let make = (~children) =>
ReactDOMRe.createPortal(
<div className="modal-container" role="dialog" ariaModal=true>
<div className="modal-content"> children </div>
</div>,
body,
);
To make the modal accessible, it should be isolated from the main application content. Using the createPortal function of ReactDOMRe, the modal is rendered directly in the body of the document.
But first, we need to access the body...
Reason ships with a Dom module. Unfortunately, the module only contains useful types in it and doesn't provide bindings to the actual DOM.
We can of course just use raw JavaScript to access document.body and type the value using the Dom module:
let body: Dom.element = [%raw "document.body"];
If we look at the compiled Modal.bs.js file, we'll see this totally unnecessary line:
var body = (document.body);
Can you imagine how the compiled code would look like if we start using this approach whenever we want to access a JavaScript value? We can do better than that!
To access the body of the document, we can use BuckleScript's external feature:
[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";
We simply tell BuckleScript to give us the value body of type Dom.element present in the global value document. This syntax is pretty smart and efficient. If we look at the compiled Modal.bs.js file, we'll see that the body is accessed directly from the document object, the same way we would do it in JavaScript!
Opening the modal
/* src/App.re */
[%bs.raw {|require('./App.css')|}];
[@react.component]
let make = () => {
let (isModalVisible, setIsModalVisible) = React.useState(() => false);
<div className="App">
<h1> {"Parent container" |> ReasonReact.string} </h1>
<h3> {"This is just a demo container" |> ReasonReact.string} </h3>
<button onClick={_ => setIsModalVisible(_ => true)}>
{"open modal" |> ReasonReact.string}
</button>
{!isModalVisible
? ReasonReact.null : <Modal> {"Foo" |> ReasonReact.string} </Modal>}
</div>;
};
To view/hide the modal, it's rendered in the App component conditionally based on the isModalVisible boolean state value.
The "open modal" button simply sets that value to true, opening the modal.
I like 👍
- Using portals is pretty simple.
- BuckleSript external syntax makes accessing a DOM element simple and efficient.
I dislike 👎
- The absence of actual bindings to the DOM. It would have made accessing the body of the document as easy as it is in JavaScript while benefiting from typing.
Iteration #2: adding close buttons
We want to have 2 buttons to close the modal:
- A cross button in the header.
- A "Close" button in the footer.
Before doing that, we need first have the modal expose:
A header component that contains the cross closing button and any elements we wish to render in the header of the modal.
A body component that contains any elements we wish to render in the body of the modal.
A footer component that will contain the second closing button and any elements we wish to render in the footer of the modal.
/* src/Modal.re */
[%bs.raw {|require('./Modal.css')|}];
[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";
module Cross = {
[@bs.module "./cross.svg"] [@react.component]
external make: unit => React.element = "default";
};
[@react.component]
let make = (~children) => {
ReactDOMRe.createPortal(
<div className="modal-container" role="dialog" ariaModal=true>
<div className="modal-content"> children </div>
</div>,
body,
);
};
module Header = {
[@react.component]
let make = (~children) => {
<div className="modal-header">
children
<button className="cross-btn" title="close modal"> <Cross /> </button>
</div>;
};
};
module Body = {
[@react.component]
let make = (~children) => <div className="modal-body"> children </div>;
};
module Footer = {
[@react.component]
let make = (~children) => <div className="modal-footer"> children </div>;
module CloseBtn = {
[@react.component]
let make = (~children) => {
<button className="close-btn" title="close modal"> children </button>;
};
};
};
We can then refactor our App.re and make use of the new modal sub-components:
/* src/App.re */
[%bs.raw {|require('./App.css')|}];
[@react.component]
let make = () => {
let (isModalVisible, setIsModalVisible) = React.useState(() => false);
<div className="App">
<h1> {"Parent container" |> ReasonReact.string} </h1>
<h3> {"This is just a demo container" |> ReasonReact.string} </h3>
<button onClick={_ => setIsModalVisible(_ => !isModalVisible)}>
{"open modal" |> ReasonReact.string}
</button>
{!isModalVisible
? ReasonReact.null
: <Modal>
<Modal.Header> {"Header" |> ReasonReact.string} </Modal.Header>
<Modal.Body> {"Body" |> ReasonReact.string} </Modal.Body>
<Modal.Footer>
<Modal.Footer.CloseBtn>
{"Close" |> ReasonReact.string}
</Modal.Footer.CloseBtn>
</Modal.Footer>
</Modal>}
</div>;
};
I like 👍
- Reason's module syntax is pretty simple and creating sub-modules is effortless.
Iteration #3: Closing the modal
Just like opening the modal, closing it can be done by setting isModalVisible in App.re to true.
Let's pass to the Modal a function, onModalClose, that does exactly that:
/* src/App.re*/
[%bs.raw {|require('./App.css')|}];
[@react.component]
let make = () => {
let (isModalVisible, setIsModalVisible) = React.useState(() => false);
<div className="App">
<h1> {"Parent container" |> ReasonReact.string} </h1>
<h3> {"This is just a demo container" |> ReasonReact.string} </h3>
<button onClick={_ => setIsModalVisible(_ => !isModalVisible)}>
{"open modal" |> ReasonReact.string}
</button>
{!isModalVisible
? ReasonReact.null
: <Modal onModalClose={() => setIsModalVisible(_ => false)}>
<Modal.Header> {"Header" |> ReasonReact.string} </Modal.Header>
<Modal.Body> {"Body" |> ReasonReact.string} </Modal.Body>
<Modal.Footer>
<Modal.Footer.CloseBtn>
{"Close" |> ReasonReact.string}
</Modal.Footer.CloseBtn>
</Modal.Footer>
</Modal>}
</div>;
};
By now, the modal component has a prop function to close the Modal. The only thing left is to make it available to the header and footer close buttons.
To do that we can expose it in a React Context Provider. Any component that needs to access the onModalClose function can then consume it using a useContext hook.
To create a context for the modal, we can use React createContext function and pass to it an initial value. Since the onModalClose function is of type unit => unit, the initial value needs to be of the same type:
let modalContext = React.createContext(() => ());
The provider can't be accessed directly from the modal's context. One way of using it is to create a provider module which exposes a make and makeProps functions:
module ContextProvider = {
let makeProps = (~value, ~children, ()) => {
"value": value,
"children": children,
};
let make = React.Context.provider(modalContext);
};
We can then wrap the modal's children inside the context provider and consume our value in the header and footer:
/* src/Modal.re */
[%bs.raw {|require('./Modal.css')|}];
[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";
module Cross = {
[@bs.module "./cross.svg"] [@react.component]
external make: unit => React.element = "default";
};
let modalContext = React.createContext(() => ());
module ContextProvider = {
let makeProps = (~value, ~children, ()) => {
"value": value,
"children": children,
};
let make = React.Context.provider(modalContext);
};
[@react.component]
let make = (~children, ~onModalClose) => {
ReactDOMRe.createPortal(
<div className="modal-container" role="dialog" ariaModal=true>
<div className="modal-content">
<ContextProvider value=onModalClose> children </ContextProvider>
</div>
</div>,
body,
);
};
module Header = {
[@react.component]
let make = (~children) => {
let onModalClose = React.useContext(modalContext);
<div className="modal-header">
children
<button
className="cross-btn"
title="close modal"
onClick={_ => onModalClose()}>
<Cross />
</button>
</div>;
};
};
module Body = {
[@react.component]
let make = (~children) => <div className="modal-body"> children </div>;
};
module Footer = {
[@react.component]
let make = (~children) => <div className="modal-footer"> children </div>;
module CloseBtn = {
[@react.component]
let make = (~children) => {
let onModalClose = React.useContext(modalContext);
<button
className="close-btn"
title="close modal"
onClick={_ => onModalClose()}>
children
</button>;
};
};
};
I like 👍
- I was able to use the Context to implement the feature, even if it was a workaround.
- After getting stuck with using the Context, I managed to get a working solution in no-time through the forum and discord channel.
I dislike 👎
- There is no documentation about using the context.
- The solution I used is undoubtedly a hack.
Iteration #4: closing the modal through a keyboard shortcut
We want to be able to close the modal by pressing the ESCAPE key. To do so, we need to use the external syntax to access 2 functions:
-
document.addEventListener(to add a listener). -
document.removeEventListener(to remove a listener).
We have to be explicit about the type of event used in both functions. The ReactEvent module provides types for various events. In our case, we are dealing with events of type Keyboard. Since our functions only deal with keyboard events, I decided to name them a bit differently:
[@bs.scope "document"] [@bs.val]
external addKeybordEventListener:
(string, ReactEvent.Keyboard.t => unit) => unit =
"addEventListener";
[@bs.scope "document"] [@bs.val]
external removeKeybordEventListener:
(string, ReactEvent.Keyboard.t => unit) => unit =
"removeEventListener";
We can then use the 2 functions to create a keydown listener that reacts to the ESCAPE key:
let keyDownListener = e =>
if (ReactEvent.Keyboard.keyCode(e) === 27) {
onModalClose();
};
The useEffect hook can be used to create a function to subscribe to our keyDownListener. The function returns than another function to clean up the effect, wrapped in an option:
/* src/Modal.re */
[%bs.raw {|require('./Modal.css')|}];
[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";
[@bs.scope "document"] [@bs.val]
external addKeybordEventListener:
(string, ReactEvent.Keyboard.t => unit) => unit =
"addEventListener";
[@bs.scope "document"] [@bs.val]
external removeKeybordEventListener:
(string, ReactEvent.Keyboard.t => unit) => unit =
"removeEventListener";
module Cross = {
[@bs.module "./cross.svg"] [@react.component]
external make: unit => React.element = "default";
};
let modalContext = React.createContext(() => ());
module ContextProvider = {
let makeProps = (~value, ~children, ()) => {
"value": value,
"children": children,
};
let make = React.Context.provider(modalContext);
};
[@react.component]
let make = (~children, ~onModalClose) => {
let keyDownListener = e =>
if (ReactEvent.Keyboard.keyCode(e) === 27) {
onModalClose();
};
let effect = () => {
addKeybordEventListener("keydown", keyDownListener);
Some(() => removeKeybordEventListener("keyDown", keyDownListener));
};
React.useEffect(effect);
ReactDOMRe.createPortal(
<div className="modal-container" role="dialog" ariaModal=true>
<div className="modal-content">
<ContextProvider value=onModalClose> children </ContextProvider>
</div>
</div>,
body,
);
};
module Header = {
[@react.component]
let make = (~children) => {
let onModalClose = React.useContext(modalContext);
<div className="modal-header">
children
<button
className="cross-btn"
title="close modal"
onClick={_ => onModalClose()}>
<Cross />
</button>
</div>;
};
};
module Body = {
[@react.component]
let make = (~children) => <div className="modal-body"> children </div>;
};
module Footer = {
[@react.component]
let make = (~children) => <div className="modal-footer"> children </div>;
module CloseBtn = {
[@react.component]
let make = (~children) => {
let onModalClose = React.useContext(modalContext);
<button
className="close-btn"
title="close modal"
onClick={_ => onModalClose()}>
children
</button>;
};
};
};
I like 👍
- useEffect being fully typed, it reminds you to clean up the effect. You either explicitly return
Noneor a cleanup function. This avoids memory leaks when adding listeners and not removing them.
I dislike 👎
- There is no documentation about the use of
useEffect.
Iteration #5: Trapping the focus in the modal
There is one more thing left in order for our modal to be properly accessible: the focus inside of it should be trapped. Once the modal is opened, we should focus the first focusable element in it. From then, pressing the TAB or SHIFT + TAB keys will only allow the user to navigate inside the modal.
We need to first create a Ref to access the modal dom element:
let modalRef = React.useRef(Js.Nullable.null);
Notice that we have to initiate useRef with a null value through the Js.Nullable module. Fortunatelty, it's pretty easy to convert from a Js.Nullable to an option:
switch(Js.Nullable.toOption(someNullable)) {
| Some(value) => ...
| None => ...
}
To select all focusable elements inside the modal, we can use the querySelector function of the DOM element inside the Ref to the modal component.
Due to the absence of proper bindings to the DOM, we either have to write our own bindings, use some 3rd party library, or just use ReactDOMRe.domElementToObj which converts the DOM element inside the modal ref into an object.
For the time being, I choose the 3rd option. This allows us to access the querySelector function easily but lose track of all types:
/* src/Modal.re */
[%bs.raw {|require('./Modal.css')|}];
[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";
[@bs.scope "document"] [@bs.val]
external addKeybordEventListener:
(string, ReactEvent.Keyboard.t => unit) => unit =
"addEventListener";
[@bs.scope "document"] [@bs.val]
external removeKeybordEventListener:
(string, ReactEvent.Keyboard.t => unit) => unit =
"removeEventListener";
[@bs.scope "document"] [@bs.val]
external activeElement: Dom.element = "activeElement";
module Cross = {
[@bs.module "./cross.svg"] [@react.component]
external make: unit => React.element = "default";
};
let modalContext = React.createContext(() => ());
module ContextProvider = {
let makeProps = (~value, ~children, ()) => {
"value": value,
"children": children,
};
let make = React.Context.provider(modalContext);
};
[@react.component]
let make = (~children, ~onModalClose) => {
let modalRef = React.useRef(Js.Nullable.null);
let handleTabKey = e => {
let current = React.Ref.current(modalRef);
switch (Js.Nullable.toOption(current)) {
| Some(element) =>
let elementObj = ReactDOMRe.domElementToObj(element);
let elements =
elementObj##querySelectorAll(
"a[href], button, textarea, input[type='text'], input[type='radio'], input[type='checkbox'], select",
);
let firstElement = elements[0];
let lastElement = elements[elements##length - 1];
if (!ReactEvent.Keyboard.shiftKey(e) && activeElement !== firstElement) {
firstElement##focus();
ReactEvent.Keyboard.preventDefault(e);
};
if (ReactEvent.Keyboard.shiftKey(e) && activeElement !== lastElement) {
lastElement##focus();
ReactEvent.Keyboard.preventDefault(e);
};
| None => ignore()
};
};
let keyListenersMap =
Js.Dict.fromArray([|("27", _ => onModalClose()), ("9", handleTabKey)|]);
let effect = () => {
let keyDownListener = e => {
let keyCodeStr = ReactEvent.Keyboard.keyCode(e) |> string_of_int;
switch (Js.Dict.get(keyListenersMap, keyCodeStr)) {
| Some(eventListener) => eventListener(e)
| None => ignore()
};
};
addKeybordEventListener("keydown", keyDownListener);
Some(() => removeKeybordEventListener("keyDown", keyDownListener));
};
React.useEffect(effect);
ReactDOMRe.createPortal(
<div className="modal-container" role="dialog" ariaModal=true>
<div className="modal-content" ref={ReactDOMRe.Ref.domRef(modalRef)}>
<ContextProvider value=onModalClose> children </ContextProvider>
</div>
</div>,
body,
);
};
module Header = {
[@react.component]
let make = (~children) => {
let onModalClose = React.useContext(modalContext);
<div className="modal-header">
children
<button
className="cross-btn"
title="close modal"
onClick={_ => onModalClose()}>
<Cross />
</button>
</div>;
};
};
module Body = {
[@react.component]
let make = (~children) => <div className="modal-body"> children </div>;
};
module Footer = {
[@react.component]
let make = (~children) => <div className="modal-footer"> children </div>;
module CloseBtn = {
[@react.component]
let make = (~children) => {
let onModalClose = React.useContext(modalContext);
<button
className="close-btn"
title="close modal"
onClick={_ => onModalClose()}>
children
</button>;
};
};
};
I like 👍
- Being able to convert from a
Js.Nullableto an option. - I was able to implement the feature regardless of the absence of proper bindings to the DOM.
I dislike 👎
- Not being able to use an option with the useRef hook.
- The absence of proper bindings to the DOM.
Top comments (8)
Thanks for the amazing article! Very useful practical info on how to implement tricky things in ReasonReact.
Just wanted to mention,
keyCodeis being deprecated according to MDN docs, instead it seems like key property is a safer choice in this case.Thanks! I'll correct that.
Hey Seif, nice article. Just fyi there is a recommended community binding to the Web API: github.com/reasonml-community/bs-w...
Nice series so far 👍 Now I have to introduce you to Mint (which I am the author of) - a language which uses React as a platform (same as Reason) and have the same semi functional approach. I have a feeling you will like it 😉
Lack of documentation is a ship stopper. Thats why Reason is a no-go area for now.
The lack of documentation surrounding Reason, Reason React, and the whole Reason / OCaml ecosystem is definitely a bummer.
It's no substitution, but Reason and OCaml code both tend to be extremely self documenting if you dive into the source code, due to the strong typing and interface files.
I'm hoping that this is an issue that can start to be solved because Reason and OCaml are both great, but without proper documentation it will be struggle to get people to adopt them in their projects.
It's also the fact that there as so few threads in Stackoverflow and Reddit. I don't even see people writing about it. Just sporadically.
I feel you, there are definitely certain gaps in the documentation. I think it's still very good documentation though. I can say that because I managed to write this series just by reading Reason & ReasonReact documentation. During the few times where I got stuck, the community on the forums & Discord was immediately helpful.