Nick Pachulski's personal blog
I have a few providers which initialize state, shove it in a context, and then ensure that the state is synchronized with AsyncStorage so that if the app is quit and restarted, the context’s state is rehydrated from AsyncStorage. A few examples of the types of state I tend to treat this way are API tokens and user IDs.
There’s a common complaint - not a problem, per se - that people run into when building applications which use React Contexts to share state.
Today I needed to test drive a feature which allows users to confirm their account. Users find their name in a list and tap a “👋 This is Me” button by it. When the button is tapped, they’re sent a text message with a 6-digit confirmation code and asked to enter it into a react native alert prompt, which is also shown on screen after the “👋 This is Me” button is tapped.
Recently I’ve been working on a universal Expo app (iOS, Android & web) intended to help my hockey team keep track of our player and game stats, track who’s RSVP’d to our weekly games, and so on. To keep track of all those things, the Expo app communicates with a restful Ruby on Rails API. I decided, for typical reasons which aren’t the subject of this post, to mock that rails API as I test drove…
Expo sets you up with a new React Native project that will run natively on Android, iOS, and in the browser with a single codebase. You can also put that same code in an Electron app to get it running as Mac and Windows desktop applications.
Tagging blog posts in jekyll is straightforward if you can use plugins like this one. However, GitHub Pages only supports a set of whitelisted plugins and I don’t see any blog-post-tagging related helpers in that list. To make Jekyll tags work on GitHub Pages, you need to create an index page for each of your tags, which is painful.
A vanity metric looks good on paper but doesn’t inform future strategies. It falsely increases confidence. Code coverage can be a vanity metric. 100% test coverage means that the test suite runs every line of production code. That doesn’t mean it exercises the code’s entire intent.
Since 2014, I’ve spent untold hours on each of 13 iOS app side projects. Three of them made it into the App Store. Not because Apple rejected the others, but because my enthusiasm for them fell away. I even stopped work on the project I consider to have been most successful, which accrued just over 2.5K users.
Most of what I’m gonna say here has already been said really well by my favorite speaker, Sandi Metz. The Don’t Repeat Yourself (DRY) principle is overemphasized and misapplied. When you need a couple of lines of code that you’ve already written, copy and paste them. Seriously.
Some function components expand to manage a range of responsibilities. Tracking which parts of the function body relate to the task at hand gets harder. Use well-named hooks to separate concerns out of the function body and into their own files.