DEV Community: Vitor Capretz

Instagram Like button in React Native and Reanimated v2

Vitor Capretz — Mon, 18 Jan 2021 09:56:30 +0000

One of the ways to make an app feel more polished is by introducing animations and transitions that lead to better visual feedback when users are interacting with your app.

For me personally, it has been fun looking for small things that I can do and will make up a great addition in the end.

Let's explore how to bring a better experience when users are toggling a "like" button by reproducing (or trying to) the Instagram version.

Why Reanimated?

React Native has its own animation APIs and they work great for a lot of cases. The issue is that for more complex scenarios it will not support running those animations in the native thread, which can cause performance issues and unresponsiveness since it then competes for resources with JavaScript.

React Native Reanimated is a library that allows developers to write smooth animations on React Native by making sure they are rendered in the native thread and not blocking JavaScript from handling other stuff at the same time.

They recently rewrote the entire library by re-thinking both the architecture and all of the APIs they provide.

One of the goals being to make it easier for developers to use and understand, so I've been using version 2 for some time and I think you should too!

As of today the v2 is in Release candidate so it will soon be ready for production.

A simple "like" button

To start a simple like button, we would need a component that can handle a press event, a state to toggle between liked and not-liked, and an icon.

If you want to follow along go to your terminal and hit npx crna --template with-reanimated2 to start a brand new React Native project with Expo and Reanimated v2 installed.

The minimal code would look like this:



import React, { useState } from "react";
import { Pressable } from "react-native";
import { MaterialCommunityIcons } from "@expo/vector-icons";

const LikeButton = () => {
  const [liked, setLiked] = useState(false);

  return (
    <Pressable onPress={() => setLiked((isLiked) => !isLiked)}>
      <MaterialCommunityIcons
        name={liked ? "heart" : "heart-outline"}
        size={32}
        color={liked ? "red" : "black"}
      />
    </Pressable>
  );
};

So we used:

useState to store and toggle the like value;
Pressable component to handle the press event, toggling the state based on the current previous value of liked;
MaterialCommunityIcons component that either shows an outline version of the heart or the filled one based on the state.

If you're following along and you render that component in a page you will have a result like this:

It works, but it's boring.

Introducing animations

Instagram's Like button brings a nice experience by fading in and out with scale its state when it's pressed.

The strategy is then to scale the non-liked version from 1 to 0 (making it disappear) and then the liked version from 0 to 1 (making it appear on top).

We start by having two icons stacked on top of each other instead of only one:



<Pressable onPress={() => setLiked((isLiked) => !isLiked)}>
  <Animated.View
    style={[
      StyleSheet.absoluteFillObject,
      { transform: [{ scale: liked ? 0 : 1 }] },
    ]}
  >
    <MaterialCommunityIcons name={"heart-outline"} size={32} color={"black"} />
  </Animated.View>

  <Animated.View style={[{ transform: [{ scale: liked ? 1 : 0 }] }]}>
    <MaterialCommunityIcons name={"heart"} size={32} color={"red"} />
  </Animated.View>
</Pressable>

Animated.View is used to wrap the icons, which we will animate. import the Animated from react-native-reanimated;
We use absolute positioning in the first view, so the other one can stay on top;
We apply the scale styles based on the state's value, nothing has changed so far. Still boring.

With this setup, we can now animate the scale. Exciting!

react-native-reanimated provides some very useful hooks for us, we will use them.

We change React's useState by Reanimated's useSharedValue, which also gives us a state, but this one can be used in both JavaScript and Native threads.



const liked = useSharedValue(0);

We will now use numbers instead of booleans so we can interpolate and use them directly into the styles as well.

The onPress event now has to be changed too since we don't have setState anymore:



onPress={() => (liked.value = withSpring(liked.value ? 0 : 1))}

Note that we use .value here to reference the actual value of the state.

withSpring is part of the magic, that is a method provided by Reanimated that tells it to change the animated value using a spring animation with default values.

Finally, we need to update the styles correctly based on the animated value, we will use useAnimatedStyle:



const outlineStyle = useAnimatedStyle(() => {
  return {
    transform: [
      {
        scale: interpolate(liked.value, [0, 1], [1, 0], Extrapolate.CLAMP),
      },
    ],
  };
});

const fillStyle = useAnimatedStyle(() => {
  return {
    transform: [
      {
        scale: liked.value,
      },
    ],
  };
});

The useAnimatedStyle hook receives a function that returns a style that gets updated based on animation values, we moved the inline styles from Animated.View to this hook instead.

For the outline style we need to interpolate the animated value in the opposite way:

If liked.value is 0 it means the scale for the outline style should be 1, if liked.value is 1 then the scale should be 0.

The fill style needs no interpolation since it follows liked.value linearly.

Here's the component so far and the current result:



const LikeButton = () => {
  const liked = useSharedValue(0);

  const outlineStyle = useAnimatedStyle(() => {
    return {
      transform: [
        {
          scale: interpolate(liked.value, [0, 1], [1, 0], Extrapolate.CLAMP),
        },
      ],
    };
  });

  const fillStyle = useAnimatedStyle(() => {
    return {
      transform: [
        {
          scale: liked.value,
        },
      ],
    };
  });

  return (
    <Pressable onPress={() => (liked.value = withSpring(liked.value ? 0 : 1))}>
      <Animated.View style={[StyleSheet.absoluteFillObject, outlineStyle]}>
        <MaterialCommunityIcons
          name={"heart-outline"}
          size={32}
          color={"black"}
        />
      </Animated.View>

      <Animated.View style={fillStyle}>
        <MaterialCommunityIcons name={"heart"} size={32} color={"red"} />
      </Animated.View>
    </Pressable>
  );
};

That is much better 🎉

If you pay close attention you'll see that the filled icon bounces too much in the end and can still be seen.

We can fix that by also styling the opacity, so it's not visible.

Change the fillStyle so it looks like this:



const fillStyle = useAnimatedStyle(() => {
  return {
    transform: [{ scale: liked.value }],
    opacity: liked.value,
  };
});

Nice one!

I posted the completed example in this gist with the entire component so you can more easily understand it and even copy/paste in our own apps.

We're done

It's always interesting to explore these smaller interactions that can make a real difference in an app, let me know if you have any others you usually apply by reaching out on Twitter.

I hope you learned something fun, and as always, I'm open to any kind of feedback at all you might have for me.

Thank's for your time 👋

This post was initially published in my own blog 😄

7 tips on how to switch teams inside your company

Vitor Capretz — Wed, 24 Jun 2020 14:53:05 +0000

First of all, I just want to acknowledge that I'm privileged enough to be in a company where I have good relationships with my managers, and where I can switch teams without a negative impact on my career. I hope other companies take note of this.

Sometimes change is not only inevitable but natural. Your goals might change, and you might want to make career moves that better align with your current goals. That might be focusing on different technologies, assuming more responsibility, working closely with people that can teach you a lot about a certain subject, or simply working on a different set of projects.

And to achieve that, you might not need to look externally, but internally.

My previous team was focused much more on Backend tasks. I really care about UX, design, and Frontend in general, that’s where I wanted to focus my career, and the natural solution would be to maybe look at different companies.

However, I love my colleagues, the company is exciting and I feel like I could do much more here. And then the stars aligned...

Last year, around September, the company I work for announced some structural changes. Some new teams were being created, and I instantly spotted one that sparked my interest. I directly scheduled a meeting with my manager to express that I would like to be a part of that team.

Here are some things I learned about the process of switching teams and that may be useful to you as well.

1 - Be aware

No matter the size of the company you work for, it will go through changes over time. New teams will be created, old teams might be merged with others, new products will arrive, and old products will be deprecated and much more.

If you are aware of these changes you will already have a head start for when you're looking for new opportunities.

Company-wide meetings can be worth attending as when changes are announced you are one of the first to know, and thus, one of the first to act. Maybe your company has an internal website with newsletters that you can subscribe to. Or your manager can tell you about the overall direction of the company over one-to-one meetings.

Be proactive, be aware.

2 - Be open

Openly express that you're available to different opportunities that might give you advantages over time.

If one of these new teams needs people with your current set of skills, and you have already mentioned to some people you would like to jump on different projects, your name may naturally come up in early-stage conversation.

By being open, you might be presented with interesting opportunities.

Be open, be ready.

3 - Maintain good relationships

In my case, I was called to a temporary project where I met and worked with some senior engineers. When this new team was being created they were the first to be included. So when I said that I would like to be part of that team and they were asked if it was a good idea, I already had them on my side.

Maintaining good relationships with your colleagues is key and you never know when you might need them supporting you.

Be nice, maintain good relationships.

4 - Create your image

In my particular case, where I'm working for a company with over 2000 employees, it can be very hard to be noticed for the work you do outside your team.

It's impossible for you to meet every engineer, every product manager, and keep track of all the people coming and going.

What you can do is to produce internal blog posts, host talks internally, offer help in open Slack channels and ask publicly when you have issues setting up some projects for instance.

Being known can give you advantages since people might already know you're a good professional and that you're a nice person to work with. It's not about being "famous" or having popularity for the sake of being cool, but it is about getting your work noticed and increasing your network.

Produce content, create your image.

5 - Be clear

Be clear about your career goals with your manager, tell them constantly about what you're trying to achieve, and what makes you happy at work.

This can be useful not only if you decide to switch teams, but if you’re clear, you might not even get to the point where you feel the need to switch teams.

If you’re clear with your goals, a good manager can help you align your goals within your current team.

But if you do come to the point where you decide to switch, they will be aware of your motives, they will not have hard feelings or have the belief that this came "out of nowhere".

Communicate more, be clear about what you’re trying to achieve.

6 - Give a reasonable notice period

This is usually a requirement that is even stated in your contract when you join a company. It states that if you would leave, you have to first complete X weeks/months for the notice period.

That can also apply when switching teams internally.

Even if it may not be a hard requirement, it's better for you to align with your current managers and have a reasonable notice period, after all, you may even go back to working with them.

If your team is the middle of a big project, it might be a good idea for you to stick around longer until they launch the MVP (Minimum Viable Product), or they might want you to help onboard a person filling your current position.

Be empathetic, give a notice period before switching to new opportunities.

7 - Be kind

I believe kindness is the key to so many things in life.

If you're switching teams, thank everyone you worked with, they all might have taught you a lot of things in the time you worked together.

Maybe even tell them that they can reach out if they come across one of the lines of code you wrote that is not clear for them.

Be thankful, be kind.

Conclusion

Many people are always looking for improvements in their careers.

By that I mean they are often looking for challenges, trying to work on interesting projects, expanding their networks, getting their work recognized, or trying to impact more and more people.

That’s not any different for me.

But maybe like me, you faced a dilemma: you liked your company, your colleagues and the business. But, you still knew you were ready for different challenges.

Instead of looking outside, I decided to look inside.

Importantly, when I decided to switch teams I made sure I would be on good terms with everyone involved. I like the company I'm working for and I want to make the best out of my time.

I hope you do too!

Follow me on Twitter @vcapretz and send me your thoughts about this subject, I would love to hear your feedback!

I hope you have a great day! 👋

Cover picture by Daria Nepriakhina on Unsplash

Writing modern Redux in 2020 - The powerful createSlice

Vitor Capretz — Fri, 24 Jan 2020 15:38:40 +0000

In my last post, I wrote a short introduction to Redux Toolkit and its basic functionalities. But I still need to talk about their most important function - called createSlice - which is probably the only one you will need to use for most applications you're writing.

What is `createSlice`?

If you've ever built an application with Redux you probably ended up with a store that contains multiple reducers, each of them dealing with certain parts of the app. Then you combine all of them in what's usually called a rootReducer, which is then used to create the store itself.

So your store creation would look something like:

Each of these key-value pairs is a "slice" of your application. You can read more about the logic for splitting reducers in the Redux documentation.

createSlice comes in handy because it deals with everything you need for each slice, so instead of calling createAction and createReducer manually, you would use one single function as a replacement.

A basic example would be:

Where the returned object from createSlice will be:

{
  name: "todos",
  reducer: (state, action) => newState,
  actions: {
    addTodo: (payload) => ({type: "todos/addTodo", payload}),
    toggleTodo: (payload) => ({type: "todos/toggleTodo", payload})
  },
  caseReducers: {
    addTodo: (state, action) => newState,
    toggleTodo: (state, action) => newState,
  }
}

So now we've got everything we need:

The name parameter will be the prefix for all of your action types,
initialState is used for the store;
The reducers are again methods in an object, where they can still mutate the state directly - thanks to immer - it works exactly like createReducer;
One action is created for each reducer, they all have the same function signature and the type property is derived from the slice name plus the reducer method - like "todos/addTodo" and "todos/toggleTodo";
The actions receive only a "payload" parameter, which is recommended according to the Flux Standard Action pattern. If you need to pass in more than one parameter, put them in an object.

Working with multiple slices

Most projects will contain many slices, it's a nice approach to separate them by features so they contain smaller logic for handling each part of the store. For these projects createSlice is probably all you're going to need, where each slice should be in separate files containing a default export for the reducer and named exports for the actions.

Putting it all together you would end up with something like:

Conclusion

Since Redux Toolkit is an opinionated tool and Redux has been more explicit about what rules you should follow and how you should structure your app, you can have the peace of mind that your apps are going to follow those rules by default.

I believe that now we are all able to write better applications with Redux, removing a lot of the boilerplate code we wrote in the past years and making it easier to maintain our codebases. Software development keeps evolving and sometimes it's natural we need to learn new things. I hope now you have enough information to start using Redux Toolkit in your projects!

Please check this page with a step by step guide on how to migrate to the new approach. And if you want to understand more deeply about some of the guidelines mentioned in this article check the Redux Style Guide page.

All feedback is welcome! Comment below if you have any questions and like the post if you enjoyed reading it 😄

Feel free to follow me - @vcapretz - on Twitter to keep in touch, my DM's are always open!

Thank you Erik Engervall for reviewing the post for me!
Cover photo by Денис Евстратов on Unsplash

Writing modern Redux in 2020 - Redux Toolkit

Vitor Capretz — Sun, 19 Jan 2020 19:58:58 +0000

I wanted to build a React Native app from scratch so I could learn new technologies and find out what I could bring to my workplace and make our app better. Trying out new technologies might be harder to do when you're working in a team for an app that already has millions of users and a couple of hundreds of contributors, such as we do at Klarna.

So I found a React Native tutorial which was simple enough for me to try stuff like react-native-navigation, styled-components and learn how to use Redux in a more modern way.

What do I mean by "Modern Redux"?

In tech, things evolve quickly and new versions of libraries we use on a daily basis are released with a frequency that makes us wonder every once in a while what the cost of updating such libraries is.

Keeping libraries up to date is important for a variety of reasons, e.g. security-vulnerabilities fixes, performance improvements and sometimes even easier implementation.

When talking about React, we recently had a huge update introducing Hooks, which enabled a lot of the libraries in the ecosystem to leverage this approach and to give developers the possibility of moving out from the class approach if they wanted to.

react-redux introduced some hooks too, which I felt was a great addition. The Redux team also introduced @reduxjs/toolkit which is what I'm going to talk about in this post.

Redux architecture and too much boilerplate

Quick disclaimer: I'm not recommending Redux nor am I going to discuss whether it's a good solution for your app, you make that decision according to your own needs and constraints.

When doing the React Native tutorial the author himself was constantly writing the default boilerplate code for setting up a Redux store with its action dispatchers, reducers and a bunch of files for each of these things.

A common approach is to have a folder that contains a file for the actions, a file for the reducer and probably a file for shared constants for action names.

But this causes discussions on whether or not they should be separate files, how you are going to deal with naming conventions, the selectors you're going to declare, etc.

Some other issues when setting up a Redux store also involve remembering not to mutate the store inside the reducers, choosing and setting up middlewares (e.g. for async actions).

Talking to a friend at Klarna about my frustrations and how I was bored just by thinking about all of this, he introduced me to the Redux Toolkit.

What is the Redux toolkit?

The above-mentioned issues (and probably a bunch more) are actually quite common and a lot of people have also shown their frustrations with them. So the Redux team came up with an opinionated toolkit to help us developers move faster by taking some decisions for us whilst making sure we don't break the conventions.

Keep in mind that anything that is opinionated might still bring frustrations for whoever doesn't agree with those opinions, but if they are from the very same people that maintain a library and set the standards for it, I would say it's good enough to trust it and move on so we can focus much more on the users and what they actually need instead of bikeshedding the same problems over and over again.

So the Redux toolkit is an opinionated tool that will handle all the common scenarios for you, removing a lot of the boilerplate code. While it will not solve all the problems you might have with Redux, it does bring benefits to the common scenarios.

Do check their docs for more examples, insights, and reasoning. But let's explore it a bit.

configureStore, createAction and createReducer

To create a simple Redux store you can use these three functions as replacements for the conventional approach.

I'll briefly introduce each of them and then show some code with each of them applied.

configureStore replaces createStore, where you can still pass your reducers and middlewares as parameters.
It provides some useful default middlewares (some of them are applied only in a development environment), redux-thunk is the chosen library as a solution for async actions.
createAction removes some of the boilerplate you usually have to write for each action, like the type parameter, how the payload looks and the argument name you will use.
The action's type is also something you need to share with the reducer so people usually have to set up a constants file to keep track of it.
createReducer is the last piece of the puzzle and the one with the most interesting differences compared to the conventional approach.
Instead of declaring a switch/case for each action type, you can use the actions themselves as parameters and have methods for how each of them should change the store's state.
Because createReducer uses immer (a library that creates the next immutable state tree while mutating the current one), you can actually mutate the state in any way you want, while still preserving the immutability required by Redux.

Code examples

So now you're probably wondering how all of this is actually implemented. I'll introduce some examples to show the basic scenarios.

The above implementation is one of the most straight forward ones, but it does show the main differences with the conventional approach:

While you do have to pass a unique identifier to the actions, you don't need to share them with the reducers. Each action now has a toString method which returns that identifier, so we use that as keys to the reducer object;
We pass the initial state as the first parameter for createReducer and an object as the second one;
The reducer itself doesn't contain a switch/case statement, each action handler is now a key in an object, we don't need to worry about unknown actions here since it will simply return the current state as it is.
Because we are using configureStore, the toolkit is adding some default middlewares for us, you can check the exact ones in the API Reference for getDefaultMiddleware.

This next example shows how we can mutate the state inside each action handler and how the toolkit handles this for us:

Pushing items to an array or modifying a value inside it directly is not recommended when writing conventional Redux, while it's nice to have immutability it may cause more confusion and be less straightforward.

This is what it would look like if you were to avoid direct mutation:

You may or may not agree with this piece of code, but now we have the option to use it.

That's it! With these examples, I hope you now have some understanding of the Redux toolkit. The toolkit also introduces a function called createSlice, I also didn't mention the hooks you can use with React and how to write async actions using redux-thunk.

Let me know if you're interested in those subjects and I’ll write more posts in the future.

Conclusion

This was a short introduction with the goal to document what I discovered about the toolkit and also, hopefully, to spark some curiosity in you.

If you want to know more, please go to the Redux toolkit quick start and then try it out in your application if you're already using Redux.

Please let me know if you have any feedback about this article and follow me on Twitter - @vcapretz to keep in touch!

Cover image by Christian Holzinger on Unsplash

Is it worth reading source code?

Vitor Capretz — Fri, 19 Jan 2018 15:32:22 +0000

Hey! I was wondering about reading source codes of libraries that you may use on a daily-basis.

Like, if I decided to learn React and Redux, it's worth taking some time to go to the source codes and dig deep into how it works? Or it's not necessary and just using it a lot will make me understand enough about it?

I don't have some clearly opinions about it and I never had really looked to a source code of something big.

Sometimes maybe it's easier because in the React example, it's also written in JavaScript, but if I wanted to understand de Node.js core I would have to understand C++, and it would take more time.

What do you think?

DEV Community: Vitor Capretz

Instagram Like button in React Native and Reanimated v2

Why Reanimated?

A simple "like" button

Introducing animations

We're done

7 tips on how to switch teams inside your company

1 - Be aware

2 - Be open

3 - Maintain good relationships

4 - Create your image

5 - Be clear

6 - Give a reasonable notice period

7 - Be kind

Conclusion

Writing modern Redux in 2020 - The powerful createSlice

What is createSlice?

Working with multiple slices

Conclusion

Writing modern Redux in 2020 - Redux Toolkit

What do I mean by "Modern Redux"?

Redux architecture and too much boilerplate

What is the Redux toolkit?

configureStore, createAction and createReducer

Code examples

Conclusion

Is it worth reading source code?

What is `createSlice`?