<h3>Attracted — Launch Day 3</h3><p>We’ve got the Freshers fair tomorrow so no partying for us today. Besides, Monday is Tank night and I’m not sure how easy it would be to talk to people while raving.</p><p>The goal tomorrow is to build brand awareness and drive app downloads which from going to these fairs in the past means giving away free shit.</p><p>Let’s go with the classic goody bag: a flier, a couple of Attracted stickers, and some sweets… simple! We can ask people to download the app to get one.</p><h4>Designing the fliers</h4><p>I tried to keep the fliers clean and generic allowing us to pivot our taglines and marketing depending on the audience, without needing to carry around a range of different fliers.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WnOo3znHsGXeYr6mxyc4nA.png" /></figure><p>The QR code is a URL that points to <a href="https://attracted.app/fliers">https://attracted.app/fliers</a> which currently redirects the user to the app on the App Store but can be easily changed if we need to. Our landing page currently handles all the static URLs on <a href="https://vercel.com">Vercel</a> through the redirects property in the <a href="https://vercel.com/docs/cli#project-configuration/redirects">vercel.json</a> file.</p><p>The giveaway will draw people to our stand but we need to make sure we tell people what the app does. Our elevator pitch is pretty nailed down, but I can’t speak to everyone myself, so I put together a quick video we can play on loop on the iPad.</p><p>Video editing isn’t something I have much experience with so after some Googling I decided to give <a href="http://wideo.co/">Wideo.co</a> a try. Pretty good result for a minimal time investment; can’t complain.</p><p>As a bit of an introvert I’m usually not jumping at the chance to talk to random people, but I’ve got to say I’m pretty excited.</p><p>If you want to try the app go to <a href="https://get.attracted.app./">https://get.attracted.app.</a> We’d love to hear any thoughts!</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=ddafec7a6126" width="1" height="1" alt="">

Attracted — Launch Day 3
We’ve got the Freshers fair tomorrow so no partying for us today. Besides, Monday is Tank night and I’m not sure how easy it would be to talk to people while raving.
The goal tomorrow is to build brand awareness and drive app downloads which from going to these fairs in the past means giving away free shit.
Let’s go with the classic goody bag: a flier, a couple of Attracted stickers, and some sweets… simple! We can ask people to download the app to get one.
Designing the fliers
I tried to keep the fliers clean and generic allowing us to pivot our taglines and marketing depending on the audience, without needing to carry around a range of different fliers.

The QR code is a URL that points to https://attracted.app/fliers which currently redirects the user to the app on the App Store but can be easily changed if we need to. Our landing page currently handles all the static URLs on Vercel through the redirects property in the vercel.json file.
The giveaway will draw people to our stand but we need to make sure we tell people what the app does. Our elevator pitch is pretty nailed down, but I can’t speak to everyone myself, so I put together a quick video we can play on loop on the iPad.
Video editing isn’t something I have much experience with so after some Googling I decided to give Wideo.co a try. Pretty good result for a minimal time investment; can’t complain.
As a bit of an introvert I’m usually not jumping at the chance to talk to random people, but I’ve got to say I’m pretty excited.
If you want to try the app go to https://get.attracted.app. We’d love to hear any thoughts!

Attracted — Launch Day 3

<h3>Attracted — Launch day 2</h3><blockquote><strong>If you want to read the series from the beginning go to </strong><a href="https://dillonerhardt.medium.com/attracted-launch-day-1-6b1dfb1c4050"><strong>Day 2</strong></a></blockquote><p>After getting some real-world feedback from drunk users last night I got straight into improving the app.</p><p>The biggest issue we saw was that the user would sign up and enter their details which would authenticate them and leave them on the discovery screen. Unfortunately, I had decided to hide users that don’t have a profile photo. Meaning the user had to go to the profile screen to add a photo for others to see them. Easy fix… let’s add a second prompt screen!</p><h4><strong>Profile photo prompt screen</strong></h4><p>To keep it super to use I decided not to try and cram the photo upload into the detail prompt screen. Instead of going for a giant button, some text with a clear call to action, and some helper text (#minor-bug add a reason why the photo should just be you).</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*UtdXDbDenRZGux0aSXWmug.png" /></figure><p>Works for now… definitely need to start adding privacy information pop-ups so people can better understand how their data is being used. Although I’m conscious that privacy education needs to be set in the right tone to not scare the user and highlight how we improve their privacy.</p><p>In the evening we got back out round the town to our favourite club this time with a little more subtle approach. We reframed our sales pitch to be focused more on user research while prompting people to validate that the issue we are trying to solve is also an issue for them too.</p><p>No major UI issues thankfully, but I’ve started taking note of what concepts might need a bit of explaining so we can add some information on app intro screens when the user first creates an account (if anyone has any suggestions for cool ways of doing that in React Native please let me know!).</p><p>Happy with the app as it is right now so just need to keep pushing the marketing 📢</p><p>If you want to try the app go to <a href="https://get.attracted.app.">https://get.attracted.app.</a> We’d love to hear any thoughts!</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=607c7e6bd7c7" width="1" height="1" alt="">

Attracted — Launch day 2
If you want to read the series from the beginning go to Day 2
After getting some real-world feedback from drunk users last night I got straight into improving the app.
The biggest issue we saw was that the user would sign up and enter their details which would authenticate them and leave them on the discovery screen. Unfortunately, I had decided to hide users that don’t have a profile photo. Meaning the user had to go to the profile screen to add a photo for others to see them. Easy fix… let’s add a second prompt screen!
Profile photo prompt screen
To keep it super to use I decided not to try and cram the photo upload into the detail prompt screen. Instead of going for a giant button, some text with a clear call to action, and some helper text (#minor-bug add a reason why the photo should just be you).

Works for now… definitely need to start adding privacy information pop-ups so people can better understand how their data is being used. Although I’m conscious that privacy education needs to be set in the right tone to not scare the user and highlight how we improve their privacy.
In the evening we got back out round the town to our favourite club this time with a little more subtle approach. We reframed our sales pitch to be focused more on user research while prompting people to validate that the issue we are trying to solve is also an issue for them too.
No major UI issues thankfully, but I’ve started taking note of what concepts might need a bit of explaining so we can add some information on app intro screens when the user first creates an account (if anyone has any suggestions for cool ways of doing that in React Native please let me know!).
Happy with the app as it is right now so just need to keep pushing the marketing 📢
If you want to try the app go to https://get.attracted.app. We’d love to hear any thoughts!

Attracted — Launch day 2

<h3>Attracted — Launch day 1</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*tPpa_nEC4HohIDAW5OPZDw.png" /></figure><p><strong>Intro:</strong> I regularly write journals to review the day and highlight the things I could have improved on and also what I’m proud of; which made me think that it would be cool to share something like that for the week I launch Attracted (https://attracted.app).</p><p>I felt rather confident going into the day, very relieved to have finally got the approved status from the Apple review team. (My pessimistic side definitely thought I was going to have to promote the beta test flight release.) The T-shirts arrived just on time as did the fliers; they came out pretty nicely.</p><p>The only coding I did today was a couple of updates to the admin dashboard to use the Apple authentication and make it look better on mobile. Oh wait… and the update to the image caching I did in the car. At that point, I was really wishing the backend was in typescript so I didn’t have to guess whether the S3 SDK Expires option was in seconds or milliseconds.</p><p>We made it into town nice and early, pumped to see all the students out on West Street. Parked up and started walking, but… I come to the very annoying realisation that I left my ID at home. Back we home we go.</p><p>We got straight into it in the queue waiting to get in, queue (see what I did there) the first realization: it’s hard to keep drunk people’s attention. Also a little moment of apprehension at first from a couple of people, I think about the concept.</p><p>Once we were finally in we got chatting with people, it was pretty fun! We found a few little issues but nothing major thankfully:</p><ul><li>Cell signal inside the club was a little limited for some people — nothing we can do about that (at least until the app is downloaded).</li><li>We really need a prompt to add at least one profile photo before you can use the app.</li><li>Even though it says “Tap &amp; hold to add image” this still needed to be explained to a few. Is it intuitive?</li></ul><p>The words “free drink voucher” really pricked some ears but, unfortunately, asking the staff lead me to the manager who promptly ignored me and kicked us out. Oh well… a little over 100 new users, some brand awareness, and a little confirmation that our social media engagement is working. I’m going to call that a win.</p><p>I spent the rest of the night setting up some targeted Instagram and Snapchat Ad campaigns and planning our approach for tomorrow.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=6b1dfb1c4050" width="1" height="1" alt="">

Attracted — Launch day 1

Intro: I regularly write journals to review the day and highlight the things I could have improved on and also what I’m proud of; which made me think that it would be cool to share something like that for the week I launch Attracted (https://attracted.app).
I felt rather confident going into the day, very relieved to have finally got the approved status from the Apple review team. (My pessimistic side definitely thought I was going to have to promote the beta test flight release.) The T-shirts arrived just on time as did the fliers; they came out pretty nicely.
The only coding I did today was a couple of updates to the admin dashboard to use the Apple authentication and make it look better on mobile. Oh wait… and the update to the image caching I did in the car. At that point, I was really wishing the backend was in typescript so I didn’t have to guess whether the S3 SDK Expires option was in seconds or milliseconds.
We made it into town nice and early, pumped to see all the students out on West Street. Parked up and started walking, but… I come to the very annoying realisation that I left my ID at home. Back we home we go.
We got straight into it in the queue waiting to get in, queue (see what I did there) the first realization: it’s hard to keep drunk people’s attention. Also a little moment of apprehension at first from a couple of people, I think about the concept.
Once we were finally in we got chatting with people, it was pretty fun! We found a few little issues but nothing major thankfully:

Cell signal inside the club was a little limited for some people — nothing we can do about that (at least until the app is downloaded).
We really need a prompt to add at least one profile photo before you can use the app.
Even though it says “Tap & hold to add image” this still needed to be explained to a few. Is it intuitive?

The words “free drink voucher” really pricked some ears but, unfortunately, asking the staff lead me to the manager who promptly ignored me and kicked us out. Oh well… a little over 100 new users, some brand awareness, and a little confirmation that our social media engagement is working. I’m going to call that a win.
I spent the rest of the night setting up some targeted Instagram and Snapchat Ad campaigns and planning our approach for tomorrow.

Attracted —  Launch day 1

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*rGeRLoujwUxdDn94iVFCZg.png" /><figcaption>RTK Query — Powerful data fetching and caching solution built on Redux</figcaption></figure><p>RTK Query is the latest addition to the Redux family and brings a much needed data fetching solution for apps using Redux to manage client side state.</p><p>GitHub: <a href="https://github.com/rtk-incubator/rtk-query">https://github.com/rtk-incubator/rtk-query</a><br>Docs: <a href="https://rtk-query-docs.netlify.app/">https://rtk-query-docs.netlify.app/</a></p><p><em>At the time of writing the library is in alpha so expect there to be changes.</em></p><h4>Overview</h4><p>The new library brings a simple data fetching API similar to <a href="https://react-query.tanstack.com/">ReactQuery</a> and <a href="https://swr.vercel.app/">SWR</a> that’s powered by Redux under the hood.</p><p>In my experience, working on large projects and reading online discussions from developers using Redux day-to-day the biggest issue is the massive flexibility and granular control you have with Redux (sounds like these <em>should</em> good things right?). For managing complex state this flexibility is amazing, but it also leaves you with quite a bit of boilerplate code when you’re doing data fetching.</p><p>Just take a look at this article <a href="https://blog.logrocket.com/data-fetching-in-redux-apps-a-100-correct-approach-4d26e21750fc/">https://blog.logrocket.com/data-fetching-in-redux-apps-a-100-correct-approach-4d26e21750fc/</a> pretty out of date (although only 2 years old) but it shows just how much code you had to write to handle just the basic states and caching in Redux.</p><p><a href="https://redux-toolkit.js.org/">Redux Toolkit</a> was great progress and really reduced the amount of boilerplate code that needed to be written but even in the official docs it’s hard to understand how to setup simple data fetching which most apps will need.</p><p>You’re probably thinking that any good developer would just create an abstraction at the beginning of the project but you’d be surprised how often that doesn’t happen for one reason or another. And even if you did, are you handing all the possible states? Are you handling polling, prefetching, re-fetching?</p><p>ReactQuery and other similar libraries really filled a gap in this area; provided a really small, simple and consistent way to fetch and cache data. They allowed developers to avoid writing this complex code for every project and focus on building the application.</p><p>RTK Query follows these other libraries (better late than never 😉) but with the weight of the larger Redux ecosystem behind it.</p><h4><strong>Where does it fit?</strong></h4><p>I think once RTK Query is production ready it will be a pretty good choice for any application.</p><p>For apps that just need <strong>simple data fetching</strong> you can use the library on it’s own with the ApiProvider that will bootstrap the Redux store for you.</p><p>Applications that are doing more <strong>complex client side state management</strong> can setup the library to <a href="https://rtk-query-docs.netlify.app/introduction/getting-started#add-the-service-to-your-store">work with their existing Redux store</a>. This is great as it allows an application to get started with RTK Query and not have to worry about implementing a separate solution or re-writing as they realise they need something more flexible… just setup <a href="https://redux-toolkit.js.org/">RTK</a> once you need it!</p><h4>Conclusion</h4><p>I’m happy to see the release of this much needed addition to <a href="https://redux-toolkit.js.org/">Redux Toolkit</a> and excited to try it out. Really impressed with the time taken to release this with the first commit being only a couple of months ago.</p><p>As with most of the Redux project the docs are fantastic and there’s an amazing community behind it which is a massive +1 🔥.</p><p>For any apps already using RTK or expecting to need the power of Redux this is a no brainer.</p><p>If you <em>only</em> need a data fetching solution then I would still suggest ReactQuery simply because, for now it is the more mature solution and provides a few more features out of the box with a smaller bundle size (<a href="https://bundlephobia.com/result?p=react-query@2.26.3">7.2kB</a> vs <a href="https://bundlephobia.com/result?p=@rtk-incubator/rtk-query@0.1.0-alpha.0">12.8kB</a> minified + gzipped).</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=392e1c8b78e3" width="1" height="1" alt=""><hr><p><a href="https://javascript.plainenglish.io/lets-review-rtk-query-392e1c8b78e3">A Review Of Redux Tool Kit Query</a> was originally published in <a href="https://javascript.plainenglish.io">JavaScript in Plain English</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

RTK Query — Powerful data fetching and caching solution built on Redux
RTK Query is the latest addition to the Redux family and brings a much needed data fetching solution for apps using Redux to manage client side state.
GitHub: https://github.com/rtk-incubator/rtk-query
Docs: https://rtk-query-docs.netlify.app/
At the time of writing the library is in alpha so expect there to be changes.
Overview
The new library brings a simple data fetching API similar to ReactQuery and SWR that’s powered by Redux under the hood.
In my experience, working on large projects and reading online discussions from developers using Redux day-to-day the biggest issue is the massive flexibility and granular control you have with Redux (sounds like these should good things right?). For managing complex state this flexibility is amazing, but it also leaves you with quite a bit of boilerplate code when you’re doing data fetching.
Just take a look at this article https://blog.logrocket.com/data-fetching-in-redux-apps-a-100-correct-approach-4d26e21750fc/ pretty out of date (although only 2 years old) but it shows just how much code you had to write to handle just the basic states and caching in Redux.
Redux Toolkit was great progress and really reduced the amount of boilerplate code that needed to be written but even in the official docs it’s hard to understand how to setup simple data fetching which most apps will need.
You’re probably thinking that any good developer would just create an abstraction at the beginning of the project but you’d be surprised how often that doesn’t happen for one reason or another. And even if you did, are you handing all the possible states? Are you handling polling, prefetching, re-fetching?
ReactQuery and other similar libraries really filled a gap in this area; provided a really small, simple and consistent way to fetch and cache data. They allowed developers to avoid writing this complex code for every project and focus on building the application.
RTK Query follows these other libraries (better late than never 😉) but with the weight of the larger Redux ecosystem behind it.
Where does it fit?
I think once RTK Query is production ready it will be a pretty good choice for any application.
For apps that just need simple data fetching you can use the library on it’s own with the ApiProvider that will bootstrap the Redux store for you.
Applications that are doing more complex client side state management can setup the library to work with their existing Redux store. This is great as it allows an application to get started with RTK Query and not have to worry about implementing a separate solution or re-writing as they realise they need something more flexible… just setup RTK once you need it!
Conclusion
I’m happy to see the release of this much needed addition to Redux Toolkit and excited to try it out. Really impressed with the time taken to release this with the first commit being only a couple of months ago.
As with most of the Redux project the docs are fantastic and there’s an amazing community behind it which is a massive +1 🔥.
For any apps already using RTK or expecting to need the power of Redux this is a no brainer.
If you only need a data fetching solution then I would still suggest ReactQuery simply because, for now it is the more mature solution and provides a few more features out of the box with a smaller bundle size (7.2kB vs 12.8kB minified + gzipped).

A Review Of Redux Tool Kit Query was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Review Of Redux Tool Kit Query

<p>As a developer you’ve probably seen or heard the famous quote;</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/638/1*4LGIZZadglcdwXSlGk4IzQ.jpeg" /><figcaption>Premature optimisation is the root of all evil</figcaption></figure><p>It serves as good advice to help you avoid overengineering and reduce time to getting user feedback. But, like most rules there’s subtalties to when it should be applied.</p><h3>The problem</h3><p>Let’s imagine… you create a component for a page your team is working on to display a small list of users.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/5b18b391fa53ff0ed79814bc78b9abb7/href">https://medium.com/media/5b18b391fa53ff0ed79814bc78b9abb7/href</a></iframe><p>As per the requirements, it takes a small list of users and sorts them by name in alphabetical order. The sort should be pretty quick since there’s only a couple of items in the array, no point prematurley optimising right?</p><p>Well, a few weeks go by and you come back from a day off, greeted by a defect with your name on. It describes your teams page being pretty slow.</p><p>You take a look and see that your UsersList component now looks a little different than when you last worked on it.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/c8d09ed7da30fb672d8e298ed97dcd23/href">https://medium.com/media/c8d09ed7da30fb672d8e298ed97dcd23/href</a></iframe><p>While you were off there was a requirment change and a junior teamate picked up the work.</p><p>Instead rendering a few users with a simple sort, the component now renders a large list of all users with a complex (and very slow!) sorting algorithm.</p><h3>Solution</h3><p>In a big team with rapidly evolving requirements as a senior engineer sometimes you need to use forward thinking and apply premature optimisations. This doesn’t mean over engineer everything, but <strong>take a moment to think what good small optimisations you can make to best set up the component you’re working on for future development</strong>.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/c06006411431172483bb0dd46d3b62e4/href">https://medium.com/media/c06006411431172483bb0dd46d3b62e4/href</a></iframe><p>Going back to our example, we need to realise that the doing a sort on a list of items is something that could potentially take a large amount of time; even if it doesn’t right now. As an optimisation we simply wrap the sort in a useMemo hook to stop it having to re compute the sorted array on each re-render, only doing it when the users array changes.</p><p>This doesn’t just set up a good foundation for future developers to work on but can also serve as a reminder for them to take a second to think about the performance of the changes their making.</p><h3>Generally applicable</h3><p>This type of beneficial premature optimisation isn’t just relevant to React, the idea of setting up good foundations to avoid performance issues can be aplied to everything from CSS to architecture.</p><h4>Warning</h4><p>Don’t spend hours working on adding nano second optimisations to all your code, just focus on the big, easy wins. It’s about balancing the time it takes to do the premature optimisation over the time it could save in the future.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=21207c05d088" width="1" height="1" alt="">

As a developer you’ve probably seen or heard the famous quote;
Premature optimisation is the root of all evil
It serves as good advice to help you avoid overengineering and reduce time to getting user feedback. But, like most rules there’s subtalties to when it should be applied.
The problem
Let’s imagine… you create a component for a page your team is working on to display a small list of users.
https://medium.com/media/5b18b391fa53ff0ed79814bc78b9abb7/href
As per the requirements, it takes a small list of users and sorts them by name in alphabetical order. The sort should be pretty quick since there’s only a couple of items in the array, no point prematurley optimising right?
Well, a few weeks go by and you come back from a day off, greeted by a defect with your name on. It describes your teams page being pretty slow.
You take a look and see that your UsersList component now looks a little different than when you last worked on it.
https://medium.com/media/c8d09ed7da30fb672d8e298ed97dcd23/href
While you were off there was a requirment change and a junior teamate picked up the work.
Instead rendering a few users with a simple sort, the component now renders a large list of all users with a complex (and very slow!) sorting algorithm.
Solution
In a big team with rapidly evolving requirements as a senior engineer sometimes you need to use forward thinking and apply premature optimisations. This doesn’t mean over engineer everything, but take a moment to think what good small optimisations you can make to best set up the component you’re working on for future development.
https://medium.com/media/c06006411431172483bb0dd46d3b62e4/href
Going back to our example, we need to realise that the doing a sort on a list of items is something that could potentially take a large amount of time; even if it doesn’t right now. As an optimisation we simply wrap the sort in a useMemo hook to stop it having to re compute the sorted array on each re-render, only doing it when the users array changes.
This doesn’t just set up a good foundation for future developers to work on but can also serve as a reminder for them to take a second to think about the performance of the changes their making.
Generally applicable
This type of beneficial premature optimisation isn’t just relevant to React, the idea of setting up good foundations to avoid performance issues can be aplied to everything from CSS to architecture.
Warning
Don’t spend hours working on adding nano second optimisations to all your code, just focus on the big, easy wins. It’s about balancing the time it takes to do the premature optimisation over the time it could save in the future.

Argument for Premature Optimisations as a Senior Engineer

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*BAUYIArrhtC1aJ5M" /><figcaption>Photo by <a href="https://unsplash.com/@williamtm?utm_source=medium&amp;utm_medium=referral">William Hook</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>The modern version of the classic science fiction book 1984. People sat on their phones scrolling through their friends photos on Instagram. As they scroll, their camera watches their face as each post comes into view. Noting which ones encite a reaction, both positive or negative, which helps improve the algorithm that is becoming ever more personalised to them. The algorithm that ensures people are seeing the content that releases the most dopamine and in turn keeps them on the app longer…but maybe this isn’t just science fiction.</p><p>I see so many articles debating whether companies like Facebook are watching you through your phone camera, and as a developer I wouldn’t doubt it for a second. Knowing how simple it is to do and how much some companies rely on data, why wouldn’t they?</p><p>Let’s look just how easy it is to implement a very basic feature like this into a simple app.</p><h3>Setup</h3><p>For this example I’m using a basic <a href="https://docs.expo.io/">Expo</a> app. Simply install the cli and run expo init face-reaction-app and pick the blank managed template.</p><h4>The app</h4><p>To demo this we’ll create a basic app that lets the user scroll through photos. We’ll use some photos from <a href="https://unsplash.com/">Unsplash</a>.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/88de643d5e3f3c03483bca87a22f7ae7/href">https://medium.com/media/88de643d5e3f3c03483bca87a22f7ae7/href</a></iframe><p>Just run yarn start to start the app.</p><h4>The goal</h4><p>We want to make sure our users are seeing photos that make them happy. The best way to check this is to flag the images that make the user smile.</p><h4>Detecting a smile</h4><p>If you asked a developer just 5 years ago to detect if a person is smiling from a live video feed, they’d probably run a mile. These days it’s literally an out of the box feature using Expo.</p><p>Just run expo install expo-face-detector expo-camera and you’ll have everything you need.</p><h4>Implementing</h4><p>First, we’ll write the detector</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/1443d66db7862ce06701b3bb3278b3ea/href">https://medium.com/media/1443d66db7862ce06701b3bb3278b3ea/href</a></iframe><p>This code creates a new component that handles the camera permissions and renders the camera with the FaceDetector <a href="https://docs.expo.io/versions/latest/sdk/facedetector/#event-shape">settings</a>, locked to the front facing camera.</p><p>The camera component has a event handler that gets called when it detects a face with a number of <a href="https://docs.expo.io/versions/latest/sdk/facedetector/#event-shape">properties</a>. We can add simple logic here to call our isSmiling prop with true if the smiling probability is over 50%, otherwise call with false .</p><p>Now we can use our new detector component in the app to show a user a message when they smile.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/414fc4cfe5f908cffe2cc48f47aa9d5e/href">https://medium.com/media/414fc4cfe5f908cffe2cc48f47aa9d5e/href</a></iframe><p>And that’s it! An image gallery app that detects a user smiling at an image, in under 100 lines of code.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*FVlGka6Q-laSx1zqcRM-Fg.gif" /></figure><h4>Overview</h4><p>The app we just built only shows a message when the user smiles but we could easily call an API to flag the images that the user smiles at. We could use that data to add a wholesome feature that lets the user look back at all the images that made them smile. Or, we could use it alongside many other data points to continuously train an AI, that decides what content to show to keep the user scrolling for longer and show them more ads.</p><p>This is just a basic example, but with a bit of work there are so many other data points that you could get from the camera:</p><ul><li>Emotion detection</li><li>Age validation</li><li>Ethnicity</li><li>Gender</li><li>Whether the user shows the screen to another person</li></ul><p>Plus many more with similar techniques using the location services, and microphone.</p><p>Although this topic is no longer a question of whether it is possible or not, now the question focuses more around how ethical this is as a form of data collection and whether this practice should really be used or not.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=f523601d2eeb" width="1" height="1" alt="">

Photo by William Hook on Unsplash
The modern version of the classic science fiction book 1984. People sat on their phones scrolling through their friends photos on Instagram. As they scroll, their camera watches their face as each post comes into view. Noting which ones encite a reaction, both positive or negative, which helps improve the algorithm that is becoming ever more personalised to them. The algorithm that ensures people are seeing the content that releases the most dopamine and in turn keeps them on the app longer…but maybe this isn’t just science fiction.
I see so many articles debating whether companies like Facebook are watching you through your phone camera, and as a developer I wouldn’t doubt it for a second. Knowing how simple it is to do and how much some companies rely on data, why wouldn’t they?
Let’s look just how easy it is to implement a very basic feature like this into a simple app.
Setup
For this example I’m using a basic Expo app. Simply install the cli and run expo init face-reaction-app and pick the blank managed template.
The app
To demo this we’ll create a basic app that lets the user scroll through photos. We’ll use some photos from Unsplash.
https://medium.com/media/88de643d5e3f3c03483bca87a22f7ae7/href
Just run yarn start to start the app.
The goal
We want to make sure our users are seeing photos that make them happy. The best way to check this is to flag the images that make the user smile.
Detecting a smile
If you asked a developer just 5 years ago to detect if a person is smiling from a live video feed, they’d probably run a mile. These days it’s literally an out of the box feature using Expo.
Just run expo install expo-face-detector expo-camera and you’ll have everything you need.
Implementing
First, we’ll write the detector
https://medium.com/media/1443d66db7862ce06701b3bb3278b3ea/href
This code creates a new component that handles the camera permissions and renders the camera with the FaceDetector settings, locked to the front facing camera.
The camera component has a event handler that gets called when it detects a face with a number of properties. We can add simple logic here to call our isSmiling prop with true if the smiling probability is over 50%, otherwise call with false .
Now we can use our new detector component in the app to show a user a message when they smile.
https://medium.com/media/414fc4cfe5f908cffe2cc48f47aa9d5e/href
And that’s it! An image gallery app that detects a user smiling at an image, in under 100 lines of code.

Overview
The app we just built only shows a message when the user smiles but we could easily call an API to flag the images that the user smiles at. We could use that data to add a wholesome feature that lets the user look back at all the images that made them smile. Or, we could use it alongside many other data points to continuously train an AI, that decides what content to show to keep the user scrolling for longer and show them more ads.
This is just a basic example, but with a bit of work there are so many other data points that you could get from the camera:

Emotion detection
Age validation
Ethnicity
Gender
Whether the user shows the screen to another person

Plus many more with similar techniques using the location services, and microphone.
Although this topic is no longer a question of whether it is possible or not, now the question focuses more around how ethical this is as a form of data collection and whether this practice should really be used or not.

Senior UI Architect

Dillon Erhardt

Community contributions

Recent activity

The state of Frontend

DevTubes

CodeUp Sheffield

Latest articles

Attracted — Launch Day 3

Attracted — Launch day 2

Attracted — Launch day 1

A Review Of Redux Tool Kit Query

Argument for Premature Optimisations as a Senior Engineer

Apps are watching you

Expertise in the latest technologies

Weekly UI Newsletter