medium

<h2>👋 Hey there</h2>
It&#8217;s been a while since I&#8217;ve provided an update on what kind of projects I&#8217;m working on. So let&#8217;s take a look at a project that I&#8217;ve been really excited about. With this project, I&#8217;ve been placing an emphasis on the user experience through proper animation, data structure, and a clean user interface. I won&#8217;t be explaining what this application is, nor its intent, only some of the things I&#8217;ve been working on within the project.
This is a real estate application that we are developing at my current job for one of our clients (names redacted). I&#8217;ve been particularly excited about this one because I knew I would be using some newer technologies with this one, specifically Redux Toolkit (RTK) and Reanimated quite heavily. With those two at play, I felt that I&#8217;d be able to develop a very robust, user-friendly application that maintained performance.
This is just a glimpse at the progress I&#8217;ve made so far, but I hope it&#8217;s insightful to where the project is going.

<h2>⏳ Loading States</h2>
Loading can be a pain&#8230; and figuring out how you want to show a user that you are loading their pertinent data can be stressful. Do you default to the age-old &#8220;loading&#8230;&#8221; message, do you display a loading spinner, a progress bar (my least favorite tbh), or do you give them a glimpse at what the next screen will look like?
Let&#8217;s be honest here&#8230; a simple &#8220;loading&#8230;&#8221; message should be reserved for the Web1 application days. It&#8217;s simply a dated, boring loading indicator. A loading spinner is a classic and fits great inside of buttons, but overtaking an entire view can be quite intrusive. Well&#8230; what about progress bars? 😴
How do you truly display what &#8220;percentage&#8221; you are at of loading the data? Progress bars just make zero sense to me when it comes to loading data. They should be saved for copying, downloading, or extracting files, not fetching json data from a server.
That leaves us with two really feasible options. My favorite? Show the user what they&#8217;re getting into! Display a loading state that has a shimmery effect of what the layout will/can look like. It doesn&#8217;t have to be 1:1, some elements may or may not be displayed based on conditions. But, we can get pretty close!

<h2>🤔 How do we do this with React Native?</h2>
It&#8217;s quite simple, really. However, it does come with its tradeoffs. First and foremost, it requires a lot of code as you&#8217;re essentially building out a replicated UI of what will (hopefully) be shown after the necessary data has been loaded and the view is rendered. In the example below I abstracted a large amount of code from the sample below just for the sake of keeping this article as short as possible.
This is a small portion of the example that is illustrated in the image above, and as you will notice, it is already a decent chunk of code. Is it worth it? I think so. I believe that it really gives the user an optimistic feeling for what their UI will look like and creates a more seamless experience for the user.
Feel free to share your thoughts with me on Twitter by mentioning me and tagging this article!

<h2>🤯 Animations</h2>
Animation is something that I find extremely important when creating an application. It&#8217;s the bridge that needs to be crossed when making a good application a great application (among many other things obviously). So what can we do on the animation front? I&#8217;ve touched on this previously in another article, <a href="https://cms.quinton.codes/react-native-progressive-image/">React Native Progressive Image,</a> but it&#8217;s crucial to have animations sync up with the user&#8217;s input.
One thing to note here is that the Animated API that is shipped with React Native is great, but it is usually at least one frame behind user input. This is because the way that the updates are communicated between the UI and JavaScript thread is asynchronous and the UI thread never waits for the JavaScript thread to finish processing events.
Here is some more information (pulled from the <a href="https://docs.swmansion.com/react-native-reanimated/docs/#motivation">reanimated docs</a>).
<blockquote>On top of the lag with JavaScript playing many roles like running react diffing and updates, executing app&#8217;s business logic, processing network requests, etc., it is often the case that events can&#8217;t be immediately processed thus causing even more significant delays. Reanimated aims to provide ways of offloading animation and event handling logic off of the JavaScript thread and onto the UI thread. This is achieved by defining Reanimated worklets – a tiny chunks of JavaScript code that can be moved to a separate JavaScript VM and executed synchronously on the UI thread. This makes it possible to respond to touch events immediately and update the UI within the same frame when the event happens without worrying about the load that is put on the main JavaScript thread.</blockquote>
Okay, great. So what are some good examples of Reanimated being used? Let&#8217;s look at inputs and buttons. In the demonstration below, you can see how the input border interpolates based on whether the input is focused and valid or not. We can also see the button color and button text colors interpolating between different sets of colors based on whether or not the inputs are valid.

<h2>💬 How do we code this?</h2>
You might be thinking to yourself, &#8220;This sounds great. What&#8217;s the catch?&#8221; Well, really&#8230; there isn&#8217;t much of a catch other than understanding a new set of APIs. With the default Animated API that ships from React Native, you have some pretty straightforward hooks to make use of. With how much more complex this package is, it is slightly more verbose and has a small learning curve.
Something I learned recently was that color interpolation can often cause a flicker if not done properly. It took me a while to figure out that instead of utilizing the libraries useSharedValue hook, I needed to be utilizing the useDerivedValue hook. What is the difference?
Show me the code already&#8230; I don&#8217;t care about this jargon. I know, I know&#8230; bear with me, it&#8217;s important to understand how this works. Let&#8217;s start with the useSharedValue hook as the useDerivedValue is quite similar, albeit slightly different.
<blockquote>Use this hook to create a reference to a JavaScript value that can be shared with worklets.
Shared Values serve a similar purpose to React Native&#8217;s <a href="https://reactnative.dev/docs/animatedvalue">Animated.Value</a>. They can carry data, provide a way to react to changes, and also drive animations.
When shared value reference is created using this hook, it can be accessed and modified by worklets. Shared Values can also be modified from the React Native thread directly, in which case the update is going to be asynchronous.
Shared Values are just javascript objects, so you can pass them to children components or define your own hooks that create them.</blockquote>
Interesting&#8230; so what is the main difference between this and a useDerivedValue?
<blockquote>This hook allows for creating shared value reference that can change in response to updating of one or more other shared values.
The hook returns the same type of a shared value reference instance as <a href="https://docs.swmansion.com/react-native-reanimated/docs/api/hooks/useSharedValue">useSharedValue</a> hook.</blockquote>
This means that we can update our value as if it were a useEffect hook without the need to wrap the update inside of a useEffect. Let&#8217;s take a look at the button component demonstrated in the video above.

Let&#8217;s take a deeper look at the code sample above. First and foremost there is one thing to explain here. You&#8217;ll notice that I am utilizing an absolutely positioned background View. The reason for this is that Reanimated does not have an Animated.createAnimatedComponent property. However, even if it did, creating Animated Touchable Opacity results in odd behavior due to the element already being animated. The way around this is a bit of a hack. However, it works quite well (I&#8217;ve not yet found a flaw while using this approach).
Okay, onto the animation code&#8230; first you&#8217;ll notice that the constant disabledValue is utilizing the useDerivedValue hook, which conditionally updates based on the disabled prop being passed to the component. When disabled is updated, we then animate our value using Reanimated&#8217;s withTiming Animation.
Then, inside of the buttonBackground, we are able to make use of interpolateColor (a Reanimated 1.x.x feature). If you&#8217;re familiar with the Animated.interpolate method, you are already good to go. It simply requires a value for which the interpolation is based, your inputRange, and your outputRange.
When doing this kind of animation on a component such as a button or an input, you are able to ensure a more up-to-date user interface based on user interaction and user data.

<h2>👾 How about RTK?</h2>
If you&#8217;ve read some of my previous blog posts, you&#8217;ll notice that I was previously using react-redux. I&#8217;m still using redux, albeit via RTK instead of the traditional containerized redux that I was using before. You can read more about that in my previous blog post, <a href="https://cms.quinton.codes/redux-persistence-typescript/">Redux, Persistence, &amp;#038; TypeScript.</a>
Side note: I still don&#8217;t fully understand why people hate on redux so much. It&#8217;s lightweight and has been the inspiration for almost every global state management feature brought to the library so far. Not only that, but the goal with redux is to do one thing, and it does it well. /rant
However, let&#8217;s talk about how I&#8217;m utilizing redux now. I&#8217;ve found that managing and maintaining your constants, redux actions, and your reducer in three separate files can be an absolute nightmare. Then updating the state within your reducer could be a nightmare as you are manually passing in your updates. Instead, RTK makes use of <a href="https://immerjs.github.io/immer/">immer</a>.
So instead of manually updating your container like this:

Your updates to your state end up being significantly simpler. Instead, they&#8217;re much more streamlined, see below.

You might be thinking that this looks quite similar, and yeah, you&#8217;re correct. The difference really shines when there are complex mutations to be made within your store. Thanks to immer, these mutations become much simpler. Not only that, but when it comes to overall code structure, we are only updating our code in one file as opposed to creating a set of actions, a set of constants, and our reducer. All of this being in one place becomes much easier to manage and maintain as the projects continue to scale.
But this is only the beginning of the information I&#8217;d like to share about RTK. There&#8217;s still RTK-Query, an optional addon included in the RTK package. I&#8217;ll share more information about RTK in an upcoming blog post as well.

<h2>✌️ Thanks for reading</h2>
If you took the time to read through this, I hope that it was insightful to you on some technologies within React Native that I personally find both powerful and useful, and that you enjoyed the read.
Let me know if you have any questions about any of these technologies by mentioning me on Twitter with a link to the article, or feel free to reach out to me through another social platform.

Well this is embarassing