Forem: Santiago Carmuega

How do you fight the developer instinct of trying to reinvent the wheel?

Santiago Carmuega — Fri, 07 Aug 2020 12:54:20 +0000

your brain is saying "use the existing tool", but deep inside you believe that building something from scratch would be better.

Anybody relates?
Any success stories about "reinventing the wheel" and gaining something from it?
Do you have any practical technique for approaching these decisions?
Where do you draw the line?

Finding middle ground between Monorepo and Polyrepo

Santiago Carmuega — Wed, 05 Aug 2020 23:34:04 +0000

A lot has been said against and in favor of each option. The discussion seems as visceral as tabs vs spaces.

Can't we find middle ground between the two?

Nobody really likes having a single 30gb-sized repo, with 200 developers pushing commits at all times, with 1000+ branches, 10+ languages and a myriad of incompatible toolchains.

At the same time, is very frustrating having to constantly switch between 20 different repos in a single day, opening and closing another 20 matching PRs, while publishing 10 different libraries just get your shinny new button into the frontend.

How do you strike a good balance between the two?

(FYI, my questions are not rhetoric, I'm really asking)

I'm inclined to think that the "scope" of a repo should be tied to two, sometimes contradicting, dimensions:

ownership boundaries
bounded contexts

Repo by Ownership Boundary

Having a single repo for all of the code owned by a single team is very practical, and by "team" I mean a group ~10 developers working together on the same backlog.

It will never grow to the size of a "mega repo" (unless your team is composed by 10x developers working 24x7 hours 😉), so you shouldn't hit any VCS limits.

Your repo interactions (PRs, issues, branching, labels, etc) can reflect a workflow tailor-made for the team, instead of compromising a workflow that fits the whole company.

The stack / toolchain of the repo should (?) be relatively cohesive since it only contains stuff selected by the members of the team.

Last but not least, if you live by the "you build it, you run it" motto, all of the CI/CD workflows would fit very nicely within the scope of this unique repo.

Repo by Bounded Context

Imagine a relatively simple subsystem within your company, composed of a web frontend, an API layer and a couple worker services. All of the above nicely orchestrated to perform intrinsically related tasks (as @alxgrk posted in the comments, a concept very well explained by DDD as Bounded Context).

Having all of the components in a unique repo allows us to push new features that span changes across all of the layers in a single cohesive and self-contained PR.

If you need to change something in your API contracts, the same PR would include the changes to the frontend layer that consumes the API, and the changes to workers that execute the actual task. Very easy to visualize, review and to fit in your mental model as a whole.

As a bonus, your deployment pipeline jobs (meaning test, QA, rollout, etc) would have a 1:1 relationship with your PRs. Nice for changelogs, awesome for rollback procedures.

Sadly, these two dimensions don't always go hand-in-hand. For example, when companies split their developers between frontend and backend teams (a very common example of independent teams handling very coupled components).

In a perfect world, your team has full ownership over a cohesive set of components, coupled between each other as much as they want, but very loosely coupled with the outside world. Under this assumption, I would most certainly prefer a single repo to manage all of the team's components.

Wouldn't you?

Asimov's "Foundation" in retrospective

Santiago Carmuega — Fri, 06 Mar 2020 12:43:40 +0000

If you had to summarize Isaac Asimov's novel "Prelude to Foundation" in today's terms:

The story of a Data Scientist named Hari Seldon and his quest for Labeled Data to train his new Machine Learning algorithm called Psychohistory.

Novel published more than 30 years ago!

useCallForward: like a callback, but forward ;)

Santiago Carmuega — Sun, 23 Feb 2020 14:01:25 +0000

We all know about callbacks in react, they provide a way for a parent component to provide the implementation of a function that is triggered by a nested component. What happens when you need the opposite? How do you trigger a command that is implemented in a nested component?

Problem

For example, lets say that you have the following app that displays a video:

+----------------------------------------------------+
|Root                                                |
|                                                    |
| +------------+ +---------------------------------+ |
| |Sidebar     | | Content                         | |
| |            | |                                 | |
| |            | |  +---------------------------+  | |
| |  +------+  | |  |                           |  | |
| |  |play  |  | |  |       video player        |  | |
| |  |button|  | |  |                           |  | |
| |  +------+  | |  |                           |  | |
| |            | |  +---------------------------+  | |
| |            | |                                 | |
| +------------+ +---------------------------------+ |
+----------------------------------------------------+

The Sidebar and the Content components are independent, they are oblivious of the existence of each other. The sidebar has a "play" button that needs to trigger the video.play() method that exists within the scope of the Content component. How would you solve that?

alternative #1, using state: The Root component has an isPlaying flag in the state, listens to the click callback of the play button and then propagates the state down to the nested Content component using props. The Content component would compare changes in the props and call the play() method accordingly. It works, but you loose the "imperative" nature of just calling a function; and you'll trigger an, otherwise unnecessary, render of the Root component.
alternative #2, using refs: The Content component bubbles up a ref of the video player onto the Root component. The Root component creates an onClick handler that triggers the play() inside the ref and then it passes the handler into the onClick callback of the Sidebar component. It also works, but bubbling things up goes against the "composite" nature of our react components.

Solution (?)

I drafted an alternative solution as a lib called react-callforward.

The basic idea of a callforward is to divide a method call into two parts: the trigger and the placeholder. The trigger is just a proxy of the actual method call. The placeholder is an empty wrapper that needs to be "implemented" by some other child component.

Take the above video app example, this is how you would solve the problem using a callforward:

function Root() {
    const [onPlay, doPlay] = useCallForward();

    return (
        <div>
            <Sidebar onClick={onPlay} />
            <Content doPlay={doPlay} />
        </div>
    )
}

function Sidebar({ onClick }) {
    return <button onClick={onClick}>play</button>
}

function Content({ doPlay }) {
    const videoEl = useRef();

    useCallHolder(() => {
        videoEl.current.play();
    }, doPlay);

    return <video ref={videoEl} />
}

The above example has been simplified for brevity. To see a running example, check the following codesandbox:

Potential

I imagine several use cases where components could be stripped away of opinionated control UI (buttons, inputs, etc), but still provide the "logic" to execute such actions:

a simple "video" component providing play, pause, scrubbing methods
any type of "data list" component providing a "refresh" method
dialogs and popup components providing an imperative "open" / "close" method (thus, hiding the open/close state within the component itself)
long text components providing "scrolling" (eg: "go to top") methods

Feedback

So... is this just another example of overengineering a simple problem? Is the idea of components exposing "methods" against the basic premise of React? Is there a more "elegant" approach that could be used in these scenarios?