Enums are an excellent way to leverage Swift’s value-types and immutability principles for handling states. Imagine you have a view that fetches a list of items from an API. You can represent that view’s state as the following enum:

enum ViewState {
  case idle,          // next state: .loading
       loading,       // next states: .items or .error
       items([Item]), // next state: .loading
       error(Error)   // next state: .loading

Your view is idle before fetching your list. When it does so, you update your view’s state to .loading and add an appropriate indicator. From there you’ll either have a successful state with the list you just loaded, or an error, much like a Result.

Now if your View, or ViewModel has a ViewState attribute, how would you render that in SwiftUI?

struct ItemsListView: View {
  @State var state: ViewState = .idle

  var body: some View {
    // TODO: render `state`

React-Native animations has some limitations on what can be done using the native driver and what can only be executed in the Javascript realm. Animating colors is an example of property you can only animate using the JS interpreter, which is super slow and will probably affect your performance. If you try and hang a few interpolates in that Animated.Value, you’ll have a bad time trying to have fluid and seemless animations.

If only there was a way of using one Animated.Value to drive another Animated.Value

thinking gif

💡 What if you use a native animation’s listener to drive a non-native animation?

I have a peculiar taste in video games. I’ve never been an avid gamer despite owning consoles and building a gaming PC when I was younger. Nontheless, a few games stuck with me even after years without playing them. Portal stood out with whole new concept of “FPS” games to me, introducing “teleport portals” you can shoot with a gun. Kerbal Space Program taught me, not only orbital mechanics, but also to appreciate astrophysics, our solar system, and endurance when facing problems that are really hard to solve.

This weekend I came accross Rogue Bit, a fun little game about computers that introduces concepts of low level programming in a really innovative way. I really admired it because it teaches while also being really fun.

To excel in any kind of art you may use an infinity of materials, technics and tools to woven a final product. Some may study their craft their whole life in order to not only improve themselves, but also to create new materials, technics and tools to be used by forthcoming generations.

To bake something as simple as a bread you need to choose the right wheat or even mix several kinds to make an unique blend. To ferment a dough, some breadmakers may use their own levain grown to perfection for years, others will use yeast, and some may even use baking powder. Then the breadmaker needs to work their dough spending hours shaping and reshaping and infusing it with herbs or other additives. Some bakers choose to not work their dough at all, and their final product will be an entirely different type of bread. For some, the final step is to bake their dough into a bread, but even for that there are many choices to make. There are those who will bake in wood ovens, others in iron pans. You may think it’s obvious that temperature plays a crucial role, but did you also know that air humidity inside the oven has a say in the bread’s crust?

Coding is no different. The programming language you’ll use may change for each problem you’re tackling. It might make sense to build a web application, or maybe an embedded system, or even a custom hardware for a specific appliance. For each of these nodes in your decision tree you may expand into different types of frameworks and tools to aid the construction of your final product.

Those who master the art of coding are artisans. Craftspersons with thousands of hours of learning, creating, tweaking, teaching, learning again… Writing code that works isn’t easy. Writing beautiful code that works is even harder. If you care about legilibilty, documentation, succinctness, then you’re probably writing beautiful code. Those who simply don’t care about any of that will hardly show interest in learning their tools and technics to the core. They won’t care about improving their own skill, let alone the machinery they use.

The ones who care, the artists, they’ll learn their craft to the bone and turn it upside down. They’ll create stuff you’ve never seen before, maybe even thought impossible. Not only they’ll make what others won’t dare, as they’ll make it beautiful to those who can understand it. Be an artisan. Know your tools. Play with them. Use them. Improve them. Practice. Break it. Fix it. Practice again. Share your knowledge. Mentor an apprentice. Share your greatness.

Turn your everyday practice into an artform.

Fork me on GitHub

Hey, I just wanted to share with you that I built a nifty little HOC to connect a hook to a component and receive its returned value as props. This helps cleanup your Function Components since you can split your states and effects into multiple hooks and simplify your code.

Imagine you have the following component:

const MyComponent = ({ userId }) => {
  const [isLoading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [result, setResult] = useState(null);

  const handlePressButton = useCallback(async () => {
    try {
      const result = await fetchDataFromTheAPI(userId);

    } catch(error) {
    } finally {
  }, []);

  const [count, setCount] = useState(0);
  const handlePressCount = useCallback(() => {
    setCount(count + 1);
  }, [count]);

  return (
      {error && <RenderError error={error} />}
      {isLoading && <Spinner />}
      {result && <RenderResult result={result}>}
      <Button onPress={handlePressButton} />

The code may look as clean as possible, but it could be better organized, and this is how you can do that.