DEV Community: Cristian Velasquez Ramos

Intuition Driven Interviews

Cristian Velasquez Ramos — Tue, 12 Apr 2022 00:43:29 +0000

Tech interviews are for the most part broken. Everyone kind of knows it, many hate it, and many more accept it.

It seems like there's a prevailing sentiment where these sort of tech interviews are a necessary evil.

To me, the current way of spitting out algorithms and asking interviewees to solve them reminds me of the North American school system. This system rewards memorization more than it does creativity or mastery.
It seems like that carried into the tech interview process.

My major gripe is that solving algorithms does not set me apart from a fresh graduate, or someone with no experience at all. Nor does it resemble the daily work of most developers.

When I hear that it requires months of preparation to pass interviews for some big companies, it makes me dread when it is time to prepare for the process all over again.

I think we can do better.

When I get the chance to conduct interviews, the type of interview I like best is asking to review some code.

I give them a piece of code that has many flaws. Many of the flaws are glaring and critical, while others are subtle. Sometimes refactors can be done that end up improving not only readability, but runtime performance. While other times it can be done just for the sake of better readability.

My goal is not for them to turn the code into the perfect piece of software, but to see what their understanding of better software is. It allows me to put into light something that is hard to express - intuition.

Granted, this intuition will vary between roles and people, but in general I've found that it makes for very relaxed interviews - since it's something that most developers do quite often (as opposed to solving code challenges).

Intuition Driven Interviews. What do you think?

On slightly easier pull requests

Cristian Velasquez Ramos — Mon, 11 Apr 2022 01:53:25 +0000

Photo by Tomáš Malík on Unsplash

Often times after getting past a tedious pull request, you know, the ones that have so many nit-picks, I wonder - how could it have gone better?

When going into a pull request, I try to focus on one thing - let's ship something that's good enough. This usually means that I focus on things like clarity and correctness, rather than aesthetics or organization.

Something that I've started to really veer away from and dislike are comments that have to do with personal preferences.

For example, many people have the preference that in a React codebase, a file should have a single component and nothing else. Anything that is not that single component should be moved to a separate file, where it be another component or a utility.

In practice, I find that this style of coding can be useful, but when overly used it becomes a real chore. Sometimes functions or components have a single use, and to have to create a whole new file to house that purpose leads to reluctance - better inline it.

Another aesthetic preference I don't really care for is line count. When does a file have too many lines? I'm not really sure. I tend to go with instinct on this. When the tree becomes convoluted in a way that makes me feel lost, I start to break things into subcomponents. Sometimes this can have benefits in performance when done well, as state can become pushed to subtrees and reduce the amount of renders happening higher up. However, if your team likes to nit on single components per file, then this sort of refactoring can become deterred as well.

I found that happening to me a lot when working with Angular. The fact that there is so much boilerplate to setting up even the simplest of components made it so I avoided it whenever I could - which lead to really hard to read components.

In general I think intuition should be applied. If the sub-component that can be made can also provide improvements that are not just aesthetic, then you should do it.

So overall, my rules are:

Is this correct?
Can I provide non-aesthetic improvements?
Is this good enough?

If so, lgtm.

Invest in your home office

Cristian Velasquez Ramos — Mon, 23 Nov 2020 16:22:05 +0000

Working from home the past couple of years (especially this one) has really made me glad that I invested in my home office. It's the place I spend the majority of my day in. It's the place I do my thinking, my planning, and my working.

It's also the place where my health can quickly deteriorate to a point of almost no return. I wonder how many people have gained/lost an unexpected amount of weight this year?

As a developer not only is that a concern, but so is the health of my wrist and hands. If I lose that, my career becomes much harder to pursue.

So the way I invested was by doing three things:

I bought an adjustable standing desk from ikea.
I bought an ergonomic mouse from logitech
I bought a treadmill you can put under the standing desk from lifespan

I actually got the treadmill idea from a streamer who bought it to stay healthy while grinding in Classic WoW. He wanted to get Rank 14, a prestigious title that requires playing for around 14 hours a day for at least 3 months

With this, my home office life has been really great. I'm able to stay healthy while I work and preserve my body for when I retire (hopefully early 😌).

There’s more I’d like to do as well. I’ve got plans on buying more plants since it’s apparently really good for you.

The next big save would be for an ergonomic chair, since those set you back quite a bit.

Try not to be stingy with your health, we've only got one body after all.

Three reasons why I love to refactor code

Cristian Velasquez Ramos — Sun, 22 Nov 2020 16:01:09 +0000

After writing some code that works, we look over it. We notice the little things that could be faster, a conditional that doesn't have to be there, logic that could be grouped and even better, code that can be deleted. We make the finishing touches and sit back and admire the fruit of our labor.

Refactoring is really a joyful activity to me. It accounts for the majority of my satisfaction when I code. A few days ago I had a sudden realization as to why I love it so much.

Refactoring is self-improvement

I love self-improvement. Especially when I can see it. When I play an instrument, there's a huge amount of satisfaction in the obvious improvements. The same applies for coding. The tidying up I do makes me feel like I just cleaned my room!

Overtime, the refactors I would do after I finish a piece of code become embedded in my first drafts. It becomes more and more apparent as you look over your code how you've grown. Am I the only that gets excited when I see good looking code?

Refactoring someone else's code (with permission) is teaching

When someone asks you to improve their code, it's a teaching opportunity. You're able to explain through action the words that are usually hard to explain. Often times, I learn more than I teach when I touch someone else's code. In the end, it's a net positive. Don't do this when not asked though, it's not a pleasant experience to see your hard work changed without warning!

Seeing my code refactored is my favourite learning experience

I love when my code is refactored. To me it's like async pair programming. I get to see how someone would solve the same problem, and since I would say that I'm not very creative, it's the inspiration I need for future similar problems.

Do you like to refactor? Let me know why!

Performant JSS

Cristian Velasquez Ramos — Mon, 02 Nov 2020 23:11:12 +0000

At work, I mainly use Material-UI. It's a really useful library that offers great defaults, great theming, and a decent, though rather complicated, styling system.

I've come to see that the most performant way to style with JSS is to do it less. Huh?

Selectors are your friend

I've realized I started to think in "components" whenever I use JSS. It's probably because it's really a react-only thing.

However, when I start to think in CSS, it suddenly makes JSS much simpler.

Intuitively we use JSS in a manner similar to this:

const styles = createStyles({
  table: {
    padding: "1rem",
  },
  tableHead: {
    fontWeight: "bold",
  },
  tableHeadCell: {
    fontSize: "0.75rem",
  },
  tableRow: {
    padding: "0.5rem",
  },
  tableRowCell: {
    fontSize: "0.5rem",
  },
});

let useStyles = makeStyles(styles);

function TableComponent(props) {
  let { items, columns } = props;
  let classes = useStyles();
  return (
    <table className={classes.table}>
      <thead className={classes.tableHead}>
        {columns.map((column) => (
          <th className={classes.tableHeadCell}>{column}</th>
        ))}
      </thead>
      <tbody>
        {items.map((row) => (
          <tr className={classes.tableRow}>
            {row.map((cell) => (
              <td className={classes.tableRowCell}>{cell}</td>
            ))}
          </tr>
        ))}
      </tbody>
    </table>
  );
}

I'm using good ol' fashion JSS here, but you can imagine the same principle with styled-components/emotion

Seems familiar right? Each style is it's own "component".

However, you can make this more performant by applying the styling once rather than to every item within the table by using one simple trick - selectors:

const styles = createStyles({
  table: {
    padding: "1rem",
    "& thead": {
      fontWeight: "bold",
      "& th": {
        fontSize: "0.75rem",
      },
    },
    "& tbody": {
      "& tr": {
        padding: "0.5rem",
        "& td": {
          fontSize: "0.5rem",
        },
      },
    },
  },
});

let useStyles = makeStyles(styles);

function TableComponent(props) {
  let { items, columns } = props;
  let classes = useStyles();
  return (
    <table className={classes.table}>
      <thead>
        {columns.map((column) => (
          <th>{column}</th>
        ))}
      </thead>
      <tbody>
        {items.map((row) => (
          <tr>
            {row.map((cell) => (
              <td>{cell}</td>
            ))}
          </tr>
        ))}
      </tbody>
    </table>
  );
}

Selectors are your friend.

GraphQL HTTP-only JWT Authentication with Next.js

Cristian Velasquez Ramos — Mon, 02 Nov 2020 01:25:39 +0000

Lately, I've been working on building one of the app challenges on devchallenges.io.

I decided to use Next.js with GraphQL as my stack. I was a little worried about how I would implement secure HTTP-only authentication but it turned out to be super simple! Let me show you how.

Starting off we'll use a basic graphql API route adapted from the next.js example

import { ApolloServer, gql } from 'apollo-server-micro'

const typeDefs = gql`
  type Query {
    me: User
  }

  type Mutation {
    signup(username: String!, password: String!): User
  }

  type User {
    username: String!
  }
`

const resolvers = {
  Query: {
    me(_parent, _args, context) {
      // what do we do here?
    },
  },

  Mutation: {
    signup(_parent, {username, password}, context) {
      // ??
    },
  }

}

const apolloServer = new ApolloServer({ typeDefs, resolvers })

export const config = {
  api: {
    bodyParser: false,
  },
}

export default apolloServer.createHandler({ path: '/api/graphql' })

Here's where the fun begins.

We'll import jsonwebtoken and cookies (make sure you add them to your dependencies!):

import jwt from "jsonwebtoken";
import Cookies from "cookies";

Then we'll add a context within the apollo server where we'll create a cookie jar to set and get cookies within our resolves and parse our JWT token (if we have it).

const verifyToken = (token) => {
  if (!token) return null;
  try {
    return jwt.verify(token, process.env.SECRET!);
  } catch {
    return null;
  }
};


const apolloServer = new ApolloServer({
  typeDefs, 
  resolvers,
  context: ({ req, res }) => {
    const cookies = new Cookies(req, res);
    const token = cookies.get("auth-token");
    const user = verifyToken(token);
    return {
      cookies,
      user,
    };
  },
});

Now in our resolvers, we can set the cookie when a user signs up (and signs in, but I'll let you figure that out):


const resolvers = {
  // ...
  Mutation: {
    async signup(_parent, {username, password}, context) {
        let hash = await bcrypt.hash(password, 10);
        // bring your own db logic
        let user = await db.createUser({username, password: hash})


        let token = jwt.sign({ id: user.id }, process.env.SECRET!);
        context.cookies.set("auth-token", token, {
          httpOnly: true,
          sameSite: "lax",
          // here we put 6 hours, but you can put whatever you want (the shorter the safer, but also more annoying)
          maxAge: 6 * 60 * 60,
          secure: process.env.NODE_ENV === "production",
        });
        return user;
    },
  }
}

Now, whenever a request is made to check our auth status, it's easy!

const resolvers = {
  Query: {
    me(_parent, _args, context) {
      // bring your own db logic
      context.user?.id ? db.findUser(context.user.id) : null
    },
  },
}

That should be enough to get you started 😄

GraphQL Code Generator in a monorepo

Cristian Velasquez Ramos — Fri, 30 Oct 2020 14:20:47 +0000

Disclaimer: this post assumes you have knowledge of how to setup a monorepo

Recently, I decided to use graphql-code-generator because I was tired of manually writing my schema definition and then writing the typescript types every single time.

With graphql-code-generator, I only have to write out the schema and the rest is, you probably guessed it, generated.

Using it within a monorepo allows you to make it so there's a single source of truth for all your API!

It will look a little something like this:

Let's map out our (basic) monorepo structure:

monorepo
 ┣ packages
 ┃ ┣ api 
 ┃ ┃ ┣ src
 ┃ ┃ ┃ ┣ index.ts 
 ┃ ┃ ┃ ┗ schema.gen.ts
 ┃ ┃ ┗ codegen.yml
 ┃ ┣ client
 ┃ ┣ server

Here's how the api codegen.yml file will look

schema: http://localhost:4000/graphql
generates:
  ./src/schema.gen.ts:
    plugins:
      - typescript

I add .gen. to all generated files to make it easy to add in .gitignore

The really cool part is when our server is running, any changes to the schema will automatically be tracked when running graphql-codegen --w inside the api package.

Now all you have to do is import @monorepo/api from your client or server and you'll have access to all the typescript types.

Using Dev.to as a CMS with Next.js

Cristian Velasquez Ramos — Thu, 29 Oct 2020 20:25:59 +0000

Thanks to @swyx for the idea and most of the logic. Check his post out.

Dev.to is a great place to share and learn from others.

It can get pretty tedious if you're busy posting blogs in two places. Luckily, Dev.to provides an API that allows you to get all your posted content for free!

If you want a full implementation, check out my website code

Here's the code I used to get it working. It has some minor changes from Swyx's code.

// postsApi.tsx

let normalizePost = (post: Post): Post => {
  const { data, content } = matter(post.body_markdown);
  return {
    ...post,
    // remove the last bit (its a 4 digit identifier, not needed here)
    slug: post.slug.split("-").slice(0, -1).join("-"),
    matter: { data, content },
  };
};

let sleep = async (ms: number = 0) => new Promise(resolve => setTimeout(resolve,ms))

export let query = async () => {
  // next does parallel builds
  // dev.to doesnt allow more than 2 requests per second (as far as I can tell
  // we gotta slow it down
  await sleep(1000)
  // we cache the response
  // otherwise we'll hit the 429 error "Too many requests" during build times
  let cached = cache.get<Post[]>();
  if (cached) return cached;

  let posts: Post[] = [];
  let page = 0;
  let per_page = 30; // can go up to 1000
  let latestResult = [];

  do {
    page += 1; // bump page up by 1 every loop
    latestResult = await fetch(
      `https://dev.to/api/articles/me/published?page=${page}&per_page=${per_page}`,
      {
        headers: {
          "api-key": process.env.dev_token as string,
        },
      }
    )
      .then((res) =>
        res.status !== 200 ? Promise.reject(res.statusText) : res.json()
      )
      .then((x) => (posts = posts.concat(x)))
      .catch((err) => {
        throw new Error(`error fetching page ${page}, ${err}`);
      });
  } while (latestResult.length === per_page);
  posts = posts.map(normalizePost);
  cache.set(posts);
  return posts;
};

Here you can see it's a simple loop aggregating all of our posts.

I've added a cache because, on my website, Dev.to would return a 429 status code because the requests were happening too fast.

This is fine since there's almost no chance our posts will become stale while we are building.

After that I call query to get a list of my posts:

// pages/blog.tsx

export async function getStaticProps() {
  let posts = await postsApi.query();
  return {
    props: {
      posts,
    },
    revalidate: 1,
  };
}

Tada! It was much smoother than I expected. Thanks a lot dev.to!

The power of patch-package

Cristian Velasquez Ramos — Thu, 29 Oct 2020 14:00:41 +0000

Have you ever been in a situation where a package has a bug that's blocking you?

Have you ever gone to the package's GitHub page, searched for an issue that matches your problem, and commented "I need this fix"?

Stop that.

What you need is patch-package.

I can't tell you enough how useful this is. Instead of having to wait for fixes to be released, I use this tool as a hotfix, and when a new version is ready that includes the fix, I simply delete the patch file it generates.

Here's an example that came up recently:

I upgraded our app to CRA 4.0 at work, but noticed that the build and rebuild times became much slower.

Looked around to find this comment inside a GitHub issue that matched my problem.

Went to node_modules/react-scripts/config/webpack.config.js like the comment said and plopped this in:

new ESLintPlugin({
    // Plugin options
    cache: true, // this
    extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
    formatter: require.resolve('react-dev-utils/eslintFormatter'),
    ...

All that was left was to run yarn patch-package react-scripts.

Aww man, it's that easy?

Yeah, it is.

Creating custom dev tools with MSW

Cristian Velasquez Ramos — Thu, 29 Oct 2020 13:58:34 +0000

If you've ever been in a situation where the API for a feature you're adding to your frontend is not ready, then MSW is for you.

At work, this is often the case for me! I have been using MSW for integration testing but I never used it for developing because I was under the impression that it would intercept and reject any requests that weren't mocked.

I was wrong.

It doesn't reject unmocked requests, it just passes it along.

I thought back to Kent C. Dodd's post on dev tools and knew that dynamically mocking API's would really speed up my development workflow (it did).

Here's how I did it.

Making sure it's dev only

// App.tsx
const DevTools = React.lazy(() => import("./DevTools"));

function App() {
  return (
    <>
      <Routes />
      {process.env.NODE_ENV === "development" ? (
        <React.Suspense fallback={null}>
          <DevTools />
        </React.Suspense>
      ) : null}
    </>
  );
}

Tada! Haha it would be great if that was all, but this is how I made sure the dev tools only loaded within the development environment. A simple dynamic component with a null suspense fallback.

This is the actual DevTools.tsx implementation:

// DevTools.tsx
import * as React from "react";
import { setupWorker, graphql } from "msw";

export const mockServer = setupWorker();

const mocks = {
  users: [
    graphql.query("GetUsers", (req, res, ctx) => {
      // return fake data
    }),
    graphql.query("GetUser", (req, res, ctx) => {
      // return fake data
    }),
  ],
};

function DevTools() {
  const [mocks, setMocks] = React.useState({});
  const mockServerReady = React.useRef(false);
  const activeMocks = React.useMemo(
    () =>
      Object.entries(mocks)
        // we filter out all unchecked inputs
        .filter(([, shouldMock]) => shouldMock)
        // since the map is an array of handlers
        // we want to flatten the array so that the final result isn't nested
        .flatMap(([key]) => mocks[key]),
    [mocks]
  );

  React.useEffect(() => {
    mockServer.start().then(() => {
      mockServerReady.current = true;
    });

    return () => {
      mockServer.resetHandlers();
      mockServer.stop();
    };
  }, []);

  React.useEffect(() => {
    if (mockServerReady.current) {
      flushMockServerHandlers();
    }
  }, [state.mock]);

  // if a checkbox was unchecked
  // we want to make sure that the mock server is no longer mocking those API's
  // we reset all the handlers
  // then add them to MSW
  function flushMockServerHandlers() {
    mockServer.resetHandlers();
    addHandlersToMockServer(activeMocks);
  }

  function addHandlersToMockServer(handlers) {
    mockServer.use(...handlers);
  }

  function getInputProps(name: string) {
    function onChange(event: React.ChangeEvent<HTMLInputElement>) {
      const apiToMock = event.target.name;
      const shouldMock = event.target.checked;

      setState((prevState) => ({
        ...prevState,
        [apiToMock]: shouldMock,
      }));
    }

    return {
      name,
      onChange,
      checked: state.mock[name] ?? false,
    };
  }

  return (
    <div>
      {Object.keys(mocks).map((mockKey) => (
        <div key={mockKey}>
          <label htmlFor={mockKey}>Mock {mockKey}</label>
          <input {...getInputProps(mockKey)} />
        </div>
      ))}
    </div>
  );
}

Let's break that down.

Mock server

Inside the DevTools.tsx file, I initialize the mock server and I add a map of all the API's I want to be able to mock and assign it to mocks. In this example I'm using graphql, but you could easily replace that with whatever REST API you may be using.

// DevTools.tsx
import { setupWorker, graphql } from "msw";

export const mockServer = setupWorker();

const mocks = {
  users: [
    graphql.query("GetUsers", (req, res, ctx) => {
      // return fake data
    }),
    graphql.query("GetUser", (req, res, ctx) => {
      // return fake data
    }),
  ],
};

UI

I make a checkbox for every key within mocks.
The getInputProps initializes all the props for each checkbox. Each time a checkbox is checked, I'll update the state to reflect which API should be mocked.

// DevTools.tsx

function DevTools() {
  const [mocks, setMocks] = React.useState({});

  function getInputProps(name: string) {
    function onChange(event: React.ChangeEvent<HTMLInputElement>) {
      const apiToMock = event.target.name;
      const shouldMock = event.target.checked;

      setState((prevState) => ({
        ...prevState,
        [apiToMock]: shouldMock,
      }));
    }

    return {
      name,
      onChange,
      checked: state.mock[name] ?? false,
    };
  }

  return (
    <div>
      {Object.keys(mocks).map((mockKey) => (
        <div key={mockKey}>
          <label htmlFor={mockKey}>Mock {mockKey}</label>
          <input {...getInputProps(mockKey)} />
        </div>
      ))}
    </div>
  );
}

Dynamic API Mocking

This part has a little more to unpack.

// DevTools.tsx
export const mockServer = setupWorker();

function DevTools() {
  const [mocks, setMocks] = React.useState({});
  const mockServerReady = React.useRef(false);
  const activeMocks = React.useMemo(
    () =>
      Object.entries(mocks)
        .filter(([, shouldMock]) => shouldMock)
        .flatMap(([key]) => mocks[key]),
    [mocks]
  );

  React.useEffect(() => {
    mockServer.start().then(() => {
      mockServerReady.current = true;
    });

    return () => {
      mockServer.resetHandlers();
      mockServer.stop();
    };
  }, []);

  React.useEffect(() => {
    if (mockServerReady.current) {
      flushMockServerHandlers();
    }
  }, [state.mock]);

  function flushMockServerHandlers() {
    mockServer.resetHandlers();
    addHandlersToMockServer(activeMocks);
  }

  function addHandlersToMockServer(handlers) {
    mockServer.use(...handlers);
  }
}

First, we create a ref to track whether the mock server is ready.

function DevTools() {
  const mockServerReady = React.useRef(false);
}

Then we create a list of all the active mocks to pass into MSW.

function DevTools() {
  const mockServerReady = React.useRef(false);
  const activeMocks = React.useMemo(
    () =>
      Object.entries(mocks)
        .filter(([, shouldMock]) => shouldMock)
        .flatMap(([key]) => mocks[key]),
    [mocks]
  );
}

When the dev tools initialize, we want to start the server, and set the mockServerReady ref to true. When it unmounts, we reset all the handlers and stop the server.

function DevTools() {
  const mockServerReady = React.useRef(false);
  const activeMocks = React.useMemo(
    () =>
      Object.entries(mocks)
        .filter(([, shouldMock]) => shouldMock)
        .flatMap(([key]) => mocks[key]),
    [mocks]
  );

  React.useEffect(() => {
    mockServer.start().then(() => {
      mockServerReady.current = true;
    });

    return () => {
      mockServer.resetHandlers();
      mockServer.stop();
    };
  }, []);
}

Finally, whenever we check a checkbox, we reset all the mocks and add whichever handlers are checked within mocks.

function DevTools() {
  const mockServerReady = React.useRef(false);
  const activeMocks = React.useMemo(
    () =>
      Object.entries(mocks)
        .filter(([, shouldMock]) => shouldMock)
        .flatMap(([key]) => mocks[key]),
    [mocks]
  );

  React.useEffect(() => {
    mockServer.start().then(() => {
      mockServerReady.current = true;
    });

    return () => {
      mockServer.resetHandlers();
      mockServer.stop();
    };
  }, []);

  React.useEffect(() => {
    if (mockServerReady.current) {
      flushMockServerHandlers();
    }
  }, [state.mock]);
}

That's all folks!

Porting my site to Reason

Cristian Velasquez Ramos — Thu, 29 Oct 2020 13:56:41 +0000

I've heard of ReasonML for a while now.

It's a language that always intrigued me since I'm a fan of FP patterns.
Well, I finally got around to really diving deep into it (aside from todos 😅).

Reason is not too different from JS/TS so the port was mainly about stripping away all the TypeScript types and letting the compiler infer the rest.

I've got to say, my favourite thing about Reason is the Rescript compiler. The inference it provides is great! It makes it so you only have to provide types at the very bottom level.

What do I mean?

Take for example this code:

module Component = {
  [@react.component]
  let make = (~name) => <div> React.string(name) </div>
}

// using the component
<Component name="Bob"/>

As you can see, I haven't declared a single type. The prop name is inferred to be a string because it's used with React.string!

The type of React.string is something like this:

module React {
  let string: string => string = //..
}

A major pain point I have though is that modeling data can be a bit of a hassle. There is no extending base types within Reason/Rescript (there is in ocaml), so something as simple as this requires copy pasting:

interface Person {
  name: sting;
}

interface Employee extends Person {
  company: string;
}

The Reason equivalent is:

type person = {
  name: string
};

type employee = {
  name: string,
  company: string
}

Yeah...

Overall, I really enjoy using Reason/Rescript. Just the inference itself is enough for me to reach for it whenever I can!

Recompose but with React Hooks!

Cristian Velasquez Ramos — Wed, 06 Feb 2019 18:17:59 +0000

When hooks were announced, I immediately looked to the library recompose to see if it was going to be updated with some hooks.

Unfortunately, the library was to be discontinued..

I decided to take the patterns of Recompose and translate them using Hooks.

The result: Re-Enhance

npm install re-enhance

yarn add re-enhance

Usage

import { pipe, usePropMapper, useStateEnhancer /* ... */ } from 're-enhance'

Recompose

const BaseComponent = props => {...}

const enhance = compose(
  withState(/*...args*/),
  mapProps(/*...args*/),
  pure
)
const EnhancedComponent = enhance(BaseComponent)

Re-Enhance

const useEnhancer = pipe(
    useStateEnhancer(/*...args*/),
    usePropMapper(/*...args*/),
    /*pure cannot be hooked 😔*/
)

// But you can use memo!
const BaseComponent = React.memo(props => {
    const enhancedProps = useEnhancer(props)
    // ...
})

Example

import React from 'react';
import { pipe, useHandlers, useStateEnhancer } from 're-enhance';

const useEnhancer = pipe(
    useStateEnhancer('counter', 'setCounter', 0),
    useHandlers({
        inc: ({ setCounter }) => () => setCounter(counter => counter + 1),
        dec: ({ setCounter }) => () => setCounter(counter => counter - 1),
    }),
);

function Component(props) {
    const { counter, inc, dec } = useEnhancer(props);
    return (
        <div>
            <button onClick={inc}>Inc</button>
            {counter}
            <button onClick={dec}>Dec</button>
        </div>
    );
}

export default Component;

Feedback wanted

Due to the limitations of Hooks, recompose could not be totally ported using React Hooks. However, I may add some of the HOC's to this project for convenience!

If you think that more Hooks can be added, feel free to contribute! 🎉🎉

DEV Community: Cristian Velasquez Ramos

Intuition Driven Interviews

On slightly easier pull requests

Invest in your home office

Three reasons why I love to refactor code

Refactoring is self-improvement

Refactoring someone else's code (with permission) is teaching

Seeing my code refactored is my favourite learning experience

Performant JSS

Selectors are your friend

GraphQL HTTP-only JWT Authentication with Next.js

GraphQL Code Generator in a monorepo

Using Dev.to as a CMS with Next.js

The power of patch-package

Creating custom dev tools with MSW

Making sure it's dev only

Mock server

UI

Dynamic API Mocking

Porting my site to Reason

Recompose but with React Hooks!

The result: Re-Enhance

Usage

Recompose

Re-Enhance

Example

Feedback wanted

Check it out!

Re-Enhance