seapig
Sea pig stands for (Children Props Internal Getter), except the C is spelled phonetically.
What does Seapig do?
seapig
.seapig
. Does whatever aseapig
does!
seapig
is here to help you compose your React Components in a consistent and flexible manner. It provides a mechanism to organize components that form into a single idea without limiting the types of components you can use.
“A way to give rendering back to the user”
seapig
eliminates configuration in favor of composition.
It abstracts component composition for you, allowing you to decouple how components are combined from which components they are. It enables you to generalize (and optionally enforce) the structure and behavior of a group of components but leaves out any restrictions on which exact components you must use.
Would render something like (play with the example):
seapig
shines the most when used to create components whose state is too complex to be held in a single component yet not global enough to be represented at the application level.
Using this pattern in React allows us to have the rendering control with the minimal api surface area without the need for configuration props for all state and data variations that our component can have.
This is where compound components come to the rescue.
A compound component encloses the state and behavior for a group of components but still gives the rendering control for its variable parts back to the external user. When using it, you only need to worry about the actual parts that are different.
A concrete example of a compound component on the Web today is the <select>
element. It allows us to externally specify its rendering structure with <option>
and <optiongroup>
elements but hides away all the complexity of rendering those in a certain way or handling/delegating events.
If you're interested in more examples of compound components, Ryan Florence has a great talk on this topic.
Good ol' seapig
twists the concept of compound components a bit by using designated props to determine distinct parts of our component group, rather than enforcing usage of specific components. Furthermore, it can restrict a consistent shape of our structure by enforcing Rendering Order and Child Presence using a schema object.
Imagine if <select>
allowed you to pass anything as its option but still handled all the logic and things like event propagation?
Wouldn't this be cool?
Rendering Order
Components that use seapig
render their children into special placeholders determined by the schema. This means that the rendering shape can be enforced internally, allowing us to pass the children into a seapig
component in any order.
Child presence
A seapig
component ensures that all children match the provided schema.
To reuse <Main>
from above as an example, if we didn't pass any children with the 'content'
prop, seapig
would throw:
The seapig
also accumulates any unidentified children into the rest
array.
In fact, OPTIONAL
and REQUIRED
, along with their plural counterparts OPTIONALS
and REQUIREDS
, are just helpful schema constants:
seapig
allows us to pass custom min
and max
, both inclusive, values as well:
Install
Example
seapig
button with a required label and an optional icon:
Walkthrough
To demonstrate the problem that seapig
solves, let's see how we can design the API of a header component.
Let's say we came up with an initial idea that the header will show a brand image to the left and a menu right after it.
Ok simple enough. Now let's consider a few potential updates we might need to make this component.
Let's imagine a requirement comes in that each page has to render a custom menu item that is unique to it, maybe some icon designated for that portion of our site that may or may not be an anchor as well.
Sure, not a problem, instead of us worrying about element types and icons for each page, let's just allow them to pass that in. Of course we don't want to render blank items if nothing is provided:
Now let's use it:
Alright, things are getting a bit messy but still manageable.
Headers usually show user info, assuming the user is authenticated.
Feels somewhat clunky but not terrible.
Phew, done. A few days go by and users now start complaining about having to navigate to /search
to explore your site and want a search bar directly in the header. Ok, we can add another flag. Additionally there isn't a point to storing this search state within the header when other parts of the app will need it so let's take that into account as well.
Did that mess things up?
You can see where this is going.
- What if we want the menu to sometimes be an
ol
rather than anul
? Theoretically, this header could be used in multiple sites. Surely we'll need to figure out how to generalize the hardcoded menu item texts for each site. Maybe a string array of items? - What if those other sites behave the same but will never need special icons?
- What if the
<input>
is sometimes only a numeric search? Pass a prop? - What if in the future we want other pages to customize the order of the internal components of
<Header>
, maybe show theinput
before theul
menu?
This is where seapig
comes in.
Let's look at how a seapig
Header
API would look like in each of these case, we'll deal with implementation later.
That's it. We mark our img
and ul
as the brand
and menu
and this satisfies all the requirements of our header for this particular page.
What about the custom icon per page? We can just render it on each page directly:
Ok, what about auth data? Well we could just mark those as well. We also want to pass the authenticated
flag to the header so it knows which items to show or not depending on the authentication
state.
What about search?
Wanna disable the search input? Just do it.
What if the <input>
is sometimes only a numeric search? We can update the type
property.
What if the menu is an ol
? We can change the tag.
Change what the items say?
Any specific rendering change we need to make to one of its children doesn't need to affect the <Header>
component itself. seapig
allows you to use whatever component you want.
Once you determine a consistent set of logic for your site or groups of pages, you can wrap that logic into a specific seapig
header component and be done with it. Any future requirements to any other system that uses the header won't affect you and you won't affect them.
So how does the actual implementation of Header
look like?
For a more advanced use case, seapig
works great with React.cloneElement
.
Let's say we want to have all auth
children add a class 'authenticated-item'
when present in the header.
API
License
MIT