This is the second post in an ongoing series where we discuss “improving how we represent our identities, what we own, and how we pay, play, and engage on the internet.” Building on our first discussion on “Shaping a Future of Digital Privacy with LLMs and Encrypted Messaging,” we next dive into the concept of data portability.

Data Portability

Why Data Portability Matters in Today’s Digital Landscape

The beginning of the twenty-first century has witnessed the digitization of virtually all data, including personal data, about each of us. This data has quickly evolved from simple information to a lucrative treasure trove for the companies whose products and services we rely on daily. The actual value of this data hinges on its efficient movement, accessibility, and portability. Many modern companies thrive not merely on the products they sell but on the data they accumulate. This shift has led to data-centric business models where the data becomes a revenue stream.

The concept of data portability is not merely a technical one; it signifies a groundbreaking shift in our perception of digital rights. Platforms have the upper hand over their users, and limited data portability is a key contributor to this power differential. Data portability is about much more than simply data transfer. True data portability would guarantee user empowerment and control and lead to a more nurturing and innovative digital environment. Users should own their digital footprints.

Significance of Data Portability

“Data portability” might seem technical, but its implications deeply touch our personal lives. The Brookings report “Data portability and interoperability: A primer on two policy tools for regulation of digitized industries” defines it as “a user’s ability to move their data from one tech service to another.” This freedom ensures competition thrives, compelling providers to innovate and prioritize user choice.

However, data portability is even more than that simple explanation can do justice. The past few decades have seen a seismic shift in how we live. From how we communicate, shop, work, and even find love, everything has been transformed by the digital revolution. Central to this transformation is data. Financial juggernauts have been built upon our data. By ensuring data portability, we’re not just talking about a technical feature but about a fundamental right in the digital age. This right may upend the current tech landscape as companies will need to find more innovative ways to attract and retain customers; profiting off their data will no longer be nearly as lucrative.

Impact of Data Portability on User Control and Innovation

In a liberated ecosystem, innovation thrives. Seamless data portability allows new market players to build on existing platforms, introducing enhanced services and features. On the flip side, restricted data portability can suppress innovation. The World Economic Forum discusses this, stating, “Genuine data portability can unleash innovations, offering users superior services and features.” The repercussions of limited data portability are multi-faceted, from dwindling competition to established platforms’ reduced incentive to innovate.

Data Silos and Their Implications

For all its advantages, the digital revolution also introduced data silos — isolated repositories that trap data, obstructing its free movement. These silos don’t just pose technical challenges; they are barriers to genuine user empowerment. As data remains confined, users face fragmented experiences and limited choices.

The existence of data silos creates multiple issues. First, they lead to redundant storage, increasing operational costs for organizations. Secondly, they hinder the holistic analysis of data. Data silos can also slow decision-making processes, as accessing and integrating data from disparate sources becomes cumbersome.

Pain Points and Limitations in Data Portability

Data portability, despite its immense potential, is laden with challenges. A significant hurdle is the absence of standardized data formats. Platforms often have proprietary formats, making seamless data transfer a complex endeavor. Moreover, concerns about data privacy and security further complicate things.

Web3

The Evolution from Web2 to Web3

Before we begin discussing web2 and comparing it to web3, let’s define the different “eras” of the internet. Web1 describes the early public internet and traces its beginnings back to the early 1990s. The release of the Mosaic web browser in 1993 is often pointed to as a key milestone that ushered in web1. This era of the internet can be thought of mainly as a “read-only” phase. In the early to mid-2000s, the web2 era began. Web2 is characterized by user-generated content, increased interactivity, and the growth of social media platforms.

Web2 was groundbreaking. However, it has also been an era where platforms capitalize on user data. As Nidal K. points out in the article “Data Ownership Revolution with Web3: How to Take Back Control of Your Data and Monetize It”, “Web 2.0 platforms created walled gardens around user data.” Web3 aims to break down these walls, giving users back their data ownership.

By leveraging blockchain technology and decentralization, users don’t just get to own their data; they get to dictate its use. It’s a shift from platform-centric models to user-centric ones. This means that in the web3 world, you won’t just be a user; you’ll be a decision-maker.

Consider current online services that operate on a centralized model. Your emails, cloud storage, and even social media posts reside on servers owned by a few corporations. Web3 proposes a model where such data could be stored on decentralized networks, giving users direct control over their information.

Monetizing Data in Web3

Web3 not only offers users control over their data but also opportunities to monetize this data. Platforms of the future might allow users to earn from their data, creating a more equitable digital landscape.

It’s not just about monetary benefits, however. With the proper mechanisms in place, users could earn better service quality, personalized experiences, or even access to premium content. Such a model could transform passive users into active stakeholders, reshaping the dynamics of the digital economy.

Redefining Data in Web3

Web3 promises a reimagined internet where users regain control and ownership of their data. This decentralized web ensures that users are not simply passive consumers but active participants earning from their data. As highlighted in the “Data Ownership in Web 3.0” article by Claude Edwin Theriault, this era champions the transition from “data as a commodity” to “data as a utility.”

This transition would be immense in terms of how we interact on the internet. Consider the current state of the internet, where large corporations often have more insight into our personal preferences than we do. Fueled by our data, their algorithms dictate the content we see, the ads we’re served, and even the products we’re offered. Web3 seeks to disrupt this paradigm.

In this scenario, you’re not just a user but a stakeholder, where every piece of data you contribute is recognized, rewarded, and respected. This isn’t a utopian dream but rather the very ethos of web3. This increased transparency could lead to greater trust in online platforms. Moreover, with users at the helm, we could see a surge in community-driven content and platforms. If anything, a “web3” internet, as described above, would resemble the original hopes for the web much more closely than what we have today. The quote below is from a February 1993 article in “The Magazine of Fantasy and Science Fiction” entitled simply “Internet.”

“Why do people want to be ‘on the Internet?’ One of the main reasons is simple freedom. The Internet is a rare example of a true, modern, functional anarchy. There is no ‘Internet Inc.’ There are no official censors, no bosses, no board of directors, no stockholders. In principle, any node can speak as a peer to any other node, as long as it obeys the rules of the TCP/IP protocols, which are strictly technical, not social or political.”

Most readers would agree that the current state of the Internet has drifted far from the optimistic vision laid out above and that the web3 vision aligns much more closely.

The Role of Cryptography

Cryptography, often behind the scenes, ensures our digital world’s security. With data becoming increasingly portable, its security and integrity are paramount. Techniques like encryption and digital signatures are crucial. They ensure data, whether moving or stationary, remains breach-resistant.

Consider the rising instances of data breaches in recent years. The need for robust security measures has never been more pressing. Cryptography acts as a defense against such threats, ensuring that our digital identities, transactions, and personal information remain secure. As we move towards a future with even more data mobility, the role of cryptography will only become more pivotal.

A cornerstone of web3’s promise is the true ownership of one’s data. This ownership is often cryptographically secured, with users holding private keys granting them access and control over their digital assets, be it cryptocurrencies or personal data. As the saying goes, “With great power comes great responsibility,” which rings true in web3.

This decentralized data ownership model places the onus of security squarely on the individual. While this empowerment is liberating, it’s also daunting. It means that the everyday user must be more tech-savvy and more security-conscious. They must understand the weight of holding their private keys and the implications of potential mismanagement.

Several web3 platforms already offer embeddable wallets and other abstractions that take key management out of users’ hands. However, these abstractions introduce a philosophical problem. If users no longer manage their private keys directly, do they genuinely own their data? By placing the responsibility of key management into the hands of third-party platforms or systems, we may reintroduce a form of centralized control. It might not be as overt as the current centralized data custodians of the web2 world, but it’s centralization nonetheless.

This shift could transform “ownership” into a more nebulous concept. Users might have access to their data, but the control embodied by the direct management of private keys might be diluted. It’s a delicate balance between usability and the essence of decentralized ownership. As the web3 ecosystem evolves, it’s a conversation that the community, developers, and users alike must engage in, ensuring that the core tenets of decentralization aren’t compromised in the pursuit of simplicity.

Data Portability in an AI-Driven Future

Role of Data Portability in AI Advancements

Artificial Intelligence (AI) sits at the cutting edge of technology. Yet, AI’s full potential can only be harnessed with access to rich, varied data. This is where data portability becomes indispensable. Data portability can enable users to transition to AI platforms that respect their rights.

In a future with true data portability, users will decide what services to share their data with and have visibility into how it is used. This data is very valuable to organizations building AI-backed solutions. This opens up an opportunity for users to monetize their data.

The union of AI and data portability signals a future where tailor-made experiences will surpass anything we’ve seen before. Picture AI-powered recommendation engines that integrate data from diverse platforms, offering truly bespoke suggestions, be it shopping, entertainment, or healthcare.

Imagine a day when your health monitor communicates seamlessly with your grocery list app. Based on your health data, the AI recommends specific foods and even integrates with local grocery stores to find the best deals. Or consider a scenario where your AI-driven virtual assistant, having access to your calendar, work tasks, personal preferences, and even mood, curates a perfect evening for you. These are not mere speculations but tangible futures enabled by AI and data portability.

How We at Catena Labs Plan to Tackle Data Portability

At Catena Labs, we’re unwavering in our vision for the web. Our ambition is a user-centric digital ecosystem liberated from centralized gatekeeper constraints. We’re pioneering innovations across domains, from identity and communication to AI and commerce.

Our journey is inspired by the understanding that in the digital realm, empowerment stems from agency. Agency over one’s data, choices, and digital interactions. This philosophy underpins every tool we design and every application we develop.

Our work with Duffle epitomizes our dedication to reshaping the digital realm. With features like rapid, encrypted messaging and personal AI chat using the XMTP protocol, Duffle forecasts a future where data isn’t just portable but genuinely empowering.

However, while we view Duffle as the best-in-class application for interacting with this data, the portable data and decentralized protocols behind the scenes make all the difference. This allows you to take your data wherever you please. You will never be locked into Duffle.

Data portability extends to the concept of group chats and communities as well. Users can create group chats or communities in Duffle and continue these conversations in any application supporting the underlying XMTP protocol. Any AI agents involved in group chats or communities are portable as well. Below is an example of communicating with Duffle AI from within Coinbase Wallet!

Jeremy Allaire on Twitter: "Excited for XMTP and Web3 wallets. See below my chat AI with a bot inside my Coinbase Wallet interacting with Duffle (@catena_labs) pic.twitter.com/zFNXLgbgX7 / Twitter"

Excited for XMTP and Web3 wallets. See below my chat AI with a bot inside my Coinbase Wallet interacting with Duffle (@catena_labs) pic.twitter.com/zFNXLgbgX7

This approach manifests our commitment to a more accessible, fairer, and user-centric digital world. A world where every byte of data, every online interaction, is rooted in respect, transparency, and empowerment.

The digital realm is vast and intricate, but with collective endeavors and a unified vision, we can craft a future where data portability is foundational, not an afterthought.

References:

1. Better AI Data Rights — Marshall Van Alstyne, Geoffrey Parker, Georgios Petropoulos and Bertin Martens, Stanford University Human-Centered Artificial Intelligence.
2. Data ownership in Web 3.0 — Claude Edwin Theriault, ModernContemporaryArtworkTrends.com, April 2023.
3. Data Ownership Revolution with Web3: How to Take Back Control of Your Data and Monetize It — Nidal K, Coinmonks blog, May 2023.
4. Data Portability and AI — IIPRD, May 2023.
5. Data Portability and Identity — Peter Grosskopf, Fractal ID Team blog, June 2021.
6. Data portability and interoperability: A primer on two policy tools for regulation of digitized industries — Sukhi Gulati-Gilbert and Robert Seamans, The Brookings Institution, May 2023.
7. Data Portability in a Data-Driven World — Frederike Zufall and Raphael Zingg, Cambridge University Press, October 2021.
8. How data portability maximizes crypto’s value — Ben White, Plaid blog, August 2022.
9. How to harness AI and data portability for greater financial inclusion — Laurent Le Moal and Amelia Ng, World Economic Forum, June 2021.
10. How web3 data portability reduces the power of centralized services — Chris Dixon, a16zcrypto, January 2022.
11. In Web 3.0, Data Ownership And Monetization Must Belong To Individuals — Jeff Bell, Forbes, March 2022.
12. 3 Reasons Why Web3 Will Flip Digital Ownership On Its Head — Ivan Liljeqvist, Entrepreneur Magazine, August 2022.

The current digital landscape presents a double-edged sword with regard to user data. On the one hand, the explosion of data has catalyzed technological advancements that make life more convenient and help keep us more connected. On the other hand, companies have capitalized on this massive influx of data, often at the cost of user privacy. Our digital footprints have become valuable assets, with companies commercializing and profiting from our most personal interactions. The proliferation of digital identities has also ushered in challenges around impersonation and false representation.

When Data Privacy Goes Wrong: High-Profile Examples

Data privacy breaches can have severe repercussions. Two high-profile examples appear below.

Cambridge Analytica

One of the most controversial cases of user data misuse involves the social media giant Meta. In 2018, it came to light that Cambridge Analytica, a political consulting firm, had obtained the personal details of millions of Facebook users without their permission and utilized it for political advertising objectives. This incident raised global concerns about Facebook’s data privacy practices and resulted in a hefty fine of $5 billion for the company.

Equifax

In 2017, major credit reporting agency Equifax disclosed a security breach that compromised the sensitive information of 147 million individuals. The stolen data contained Social Security numbers, birth dates, addresses, and even driver’s license numbers, all of which could be exploited for identity theft purposes. This case highlighted the vulnerability of centralized data storage systems and questioned the efficacy of existing data protection mechanisms.

The lack of privacy and respect for personal data has reached a tipping point in recent years, necessitating legislation like the General Data Protection Regulation (GDPR). Yet, we should not have to rely solely on regulatory safeguards. As custodians of this digital landscape, we should prioritize user privacy instead of waiting for legislation to enforce it.

Privacy in Duffle

At Catena Labs, we firmly believe that privacy is not just a feature but an essential cornerstone of AI-backed digital products. One of our product initiatives, Duffle, embodies this principle.

Duffle enables people to utilize decentralized identities and portable profiles to engage in encrypted chats with groups and individuals — and also interact with private AI agents. It employs secure data-sharing mechanisms, privately-hosted Large Language Models (LLMs), and encrypted messaging protocols. It is about fostering a new era of digital interaction, one where your data and conversations are your own.

Private Data: An Essential Ingredient for Personalized AI

In today’s digital age, data is akin to gold. However, this data “gold” isn’t locked away in some safe; it’s often out in the open, accessible to anyone with the right tools and the willingness to exploit it. The data we generate as we navigate digital spaces, interact with platforms, and engage with AI, is frequently consumed by corporations and used to further their interests, often without our informed consent. In this scenario, our data — an extension of our identity, preferences, and behavior — should not just be treated as an asset; it should remain strictly private, forming the essential cornerstone of a truly personalized AI experience.

Drawing a parallel to human relationships, it becomes evident that trust is the bedrock upon which any impactful relationship is built. The cornerstone of trust, whether between friends, family members, or business associates, is confidentiality. The more trust you have in someone, the more personal information you are willing to share with them. The relationships we foster with AI should be no different.

Users will trust AI-backed tools when they know that their personal information cannot be misused or manipulated and that they have complete control over their private data. Understanding that our data remains confidential, is treated with respect, remains under our control, and is used solely to enhance our experiences is critical to fostering this trust. The assurance of this trust and control encourages individuals to willingly share more specific and personal information, thus paving the way for genuinely individualized and contextual AI experiences.

In Duffle, Catena Labs is championing the cause of private data. Users can share their personal data securely with their own personal and private AI agent, ensuring they reap the benefits of a tailored AI experience without risking their privacy. Imagine having an AI assistant who knows you very well and is constantly optimizing for your needs while maintaining a strict code of confidentiality.

Privately-Hosted LLMs: Conversation Privacy at the Core

While AI continues to make significant strides, a crucial challenge persists: ensuring conversation privacy. In traditional models, conversations with AI often contribute to training public models, potentially compromising user privacy. While contributing significantly to the AI’s learning and adaptability, this process could inadvertently compromise user privacy. It may expose private and sensitive content of conversations that a user may not want to be used beyond the specific interaction. To tackle this, we need a new approach — privately-hosted LLMs with encrypted personal embeddings and secure private plugins.

In Duffle, we aim to address privacy concerns through the use of privately-hosted LLMs. This measure ensures that the content of your interactions with the AI, and the conversations that you hold, remain confidential and do not contribute to training publicly accessible models. This privacy-first approach addresses potential privacy issues and comes with a dual benefit.

Our privately-hosted LLMs are designed to maintain user privacy and adapt to individual users’ needs and preferences. The models can learn from each conversation and interaction, providing personalized responses and improving the user experience without sharing personal data with public LLMs. We ensure that any data used in this way is not shared or used in any manner to which you, as the user, have not explicitly consented.

At Catena, we place conversation privacy at the core of our operations. With the power of privately-hosted LLMs, we ensure that our users can leverage the benefits of AI technology, enjoying highly personalized and efficient responses, all while their conversation privacy remains uncompromised.

Private Communication: The Power of Encrypted Networks

We live in an era where most of our communication is executed digitally. From personal messages to business transactions, we rely heavily on the digital world, underscoring the importance of secure and private digital interactions. Encryption is the stalwart guard that ensures our digital messages and data remain safe from unauthorized access or accidental leaks. It serves as a shield that protects the privacy of our conversations and the security of our data in a landscape where cyber threats are always present.

Duffle leverages the robust capabilities of encrypted networks to provide this crucial safeguard. Specifically, we leverage the eXtensible Message Transport Protocol (XMTP). This protocol is designed to facilitate secure, encrypted communication, a vital layer of protection that safeguards both the content and the context of interactions between users and their AI agents.

We harness the power of end-to-end encryption, ensuring only the intended recipient can decrypt and access the communication. Every bit of data is encrypted from the moment a message is sent to the moment it’s received. This encryption includes your interactions with your AI agent. This approach fortifies the privacy and security of your communications and guarantees the confidentiality of your data.

With Duffle’s implementation of XMTP and end-to-end encryption, privacy will not just be a theoretical concept or a luxury feature but the backbone of every interaction and transaction you undertake. It’s not just about making private, secure conversation channels with your AI possible — at Catena, we’re making it the new normal.

The Power of Private AI Agents

As we move towards a more AI-driven digital environment, the conversational nature of AI tools becomes increasingly vital. This is especially true as AI begins to permeate more aspects of our personal and professional lives. Private AI agents, like those utilized within Duffle, can redefine this interaction by providing a personalized touch.

AI, especially LLMs, have made significant strides in understanding human language and context. They can generate human-like text to engage, entertain, and educate. However, these conversations are often generic and lack personalization since the AI has no specific context or knowledge about the individual user.

That’s where private AI agents come in. Imagine having an AI assistant that knows your work habits, understands your interests, or remembers that obscure movie reference you made weeks ago. It’s not just about data; it’s about personalized, contextual data. It can provide tailored recommendations, reminders, and insights based on your unique needs and preferences.

Duffle’s approach combines the power of LLMs with the promise of data privacy. With personal, privately-hosted LLMs that you control, you have an AI assistant that can learn from your data over time without sharing or exploiting this information.

In an era where our digital and physical lives are intertwined, this personalized, privacy-first approach can dramatically enhance the user experience while safeguarding individual privacy. It can be a game-changer for individuals and organizations, opening up new ways of interacting with AI.

Embracing this privacy-centric approach is not just about avoiding past mistakes; it’s about paving the way for a more secure, personalized, and user-friendly digital future.

The Road Ahead

As we navigate this exciting digital journey, protecting user privacy and data is paramount. Duffle, with its focus on private data, privately-hosted LLMs, and encrypted communication, is a pioneering initiative in this direction. By providing users with a truly private, secure platform for interacting with AI, we are revolutionizing the user experience and laying the foundation for a privacy-first digital future.

Privacy isn’t just a feature. It is an integral aspect of your digital life. It is the future we at Catena Labs are diligently working towards. And it’s a future where your data is truly your own.

We invite you to join the journey! We’re humbled and thankful for the feedback of our earliest Dufflers, and we’re now thrilled to invite more individuals off our waitlist to explore Duffle’s alpha.

To request access to iOS or Android versions, visit the codename // Duffle site: https://duffle.chat

Over the past couple of weeks, a phrase that has its origins in modern military slang keeps entering my mind: “embrace the suck.” This phrase was popularized by soldiers during the original Operation Iraqi Freedom and as this Los Angeles Times story notes, it loosely translates to,

“Face it, soldier; I’ve been there. War ain’t easy. Now deal with the difficulty and let’s get on with the mission.”

There’s an added wrinkle to what much of the world is currently enduring, isolation. We have been asked to practice social distancing, to shelter-in-place, to self-quarantine. With this in mind, we basically need to “embrace the stuck!”

We are stuck at home day after day. Most of us are working from home, many for the first time. Some of us are attempting to do so while chasing kids around; kids who are out of school indefinitely. This is a big change for all of us, but I will argue that there are opportunities in this period of uncertainty.

Those of us who are fortunate enough to be healthy and unaffected physically by the coronavirus should be thankful. Sure, it’s OK to be frustrated. Yes, you may feel burnt out from attempting to perform double-duty, working and chasing kids around. On the other end of the spectrum, you may have recently lost your job. That sucks. Plain and simple. But at the end of the day, I promise, there is opportunity here.

Over a decade ago, in late 2008, I moved from Los Angeles back to Massachusetts as the economy was collapsing. I had no job prospects and within a week went from living on Sunset Blvd to living in a two-bedroom apartment with my sister. I felt stressed, isolated, but never defeated. My girlfriend at the time, who would soon become my wife, suggested I look into actuarial science as I had always been a “math nerd.”🤓 Soon after, I purchased the necessary books and study guides and began working toward taking the first actuarial exam. Through self-study, I passed the first two actuarial exams and by early 2010 had secured a solid job at an insurance company. This indirectly led to my current career as a software engineer, a career I may have never found had I not taken initiative back in one of the toughest periods of my life.

Take advantage of this isolation period as much as you can. Put together a reading list and work through it consistently to learn a new skillset. Finally follow through on that goal to learn to code and enroll in an online program.💻 Pick up that paintbrush again and start creating.🎨 Put pen to paper and begin writing that book you’ve always talked about wanting to write.📝 Whatever it is, take advantage of this very difficult period in history. Work toward coming out of this period with new or improved skill sets. That will set you apart in the future competitive job market.🚀

We are sadly losing many thousands of people to this virus. Honor them by not wasting a second of the time we are fortunate to still have.

#EmbraceTheStuck!!!

Note: I plan on donating any proceeds I may earn on this story through the Medium Partner Program to Girls Who Code. I have been fortunate to work with some incredible women engineers but when I look around I realize this profession is still dominated by men. I would like to do my own small part to help change this!

If you’ve ever considered pursuing a career in software engineering but thought you were too old or that your education and career path up to this point weren’t a fit, think again! My path to a career in software engineering is detailed below and let’s just say it was not a straight line, but it was well worth it!

The weather geek

For as long as I can remember I have been fascinated by the weather. Some of my fondest memories as a child were peering out the window as a severe thunderstorm rolled in or waking up in the morning to a raging blizzard outside. My favorite number was, and still is, 56 due to the fact that The Weather Channel was 56 on our cable package.

Throughout my teenage years, I was the local weather spotter for Boston’s ABC affiliate. I would call in local conditions and snowfall amounts during storms and would be mentioned on-air once in awhile. I knew my future career was going to be in meteorology and no one could tell me anything different.

I was a solid student throughout my childhood and decided to only apply to one school, Penn State University. Penn State has one of the best, if not the best, meteorology programs in the nation. I received my acceptance letter before Halloween of my senior year of high school. Everything was falling into place for this future meteorologist…or so I thought.

Total lines of code written by age 18: 0

Skills gained which would eventually help my engineering career: embracing a passion (meteorology) and being a self-starter in learning more about a field

A national tragedy and a change of course

Within the first month of college, my classmates and I were informed that there was a great chance none of us would graduate with a Meteorology degree. I remember all of us laughing out loud. We had all been weather geeks since we could walk. Noooo chance we would change majors.

By the beginning of my sophomore year of college, I started to get bored with my meteorology courses. I loved tornados, hurricanes, blizzards but these extreme weather events do not happen very often. I remember overhearing classmates arguing about whether that night’s low temperature would be 37º or 38º one day and all I was concerned with was where I was going to party that night. It was clear that I needed to make a change, but when you’ve been known as the “future meteorologist” since age five it can be very difficult to tell those you love that that dream is over.

I had my first Computer Science course scheduled for the fall of 2001 but after just one class I dropped it. I decided that computer science was just not for me and my time was better spent in a different class. Oh, silly 20-year-old me ;)

My sophomore year began in the fall of 2001 and on September 11 any childhood innocence I may have had left was gone. Meteorology suddenly felt even less important to me as I began to look for a major, and a future career, where I could have a greater impact.

Around this same time, I attended a free speaker series event on the University Park campus. Chuck D of Public Enemy fame was the speaker that evening. I still remember to this day when he looked out at the audience and urged us, students, not to “waste our time at a great university pursuing someone else’s dream”. That was the push I needed and the very next day I began filling out paperwork to change my major.

I moved to Washington D.C. after graduating from Penn State and within a year was working as a Data Analyst on an Immigration and Customs Enforcement (ICE) contract.

Total lines of code written by age 22: 0

Skills gained which would eventually help my engineering career: time management, advanced mathematics, improved logical thinking

Jaded and restless

I entered my career in Homeland Security with a vision that I would be “protecting the country from terrorists”. This is not what I experienced in reality. It quickly became apparent to me that my job was mostly busy work and that the contractor I was working for was much more interested in securing more Federal contracts while appearing to “fight terrorism” than actually fighting terrorism. In my 2.5 years on the job, I can honestly admit that my work contributed to zero terrorist apprehensions.

I was pretty frustrated at this point but thankfully had the gym as an outlet. Every day after work I would spend a solid two hours lifting weights. I would then go home and prepare eggs, oatmeal, chicken, and sweet potatoes for the next day’s meals. This lifestyle eventually led to a couple of local photoshoots and the opportunity to work with a manager to further this side career. I did some work for Under Armour and Simpson Racing and quickly got the itch to move West to Hollywood to see what I could make out of this opportunity.

Total lines of code written by age 25: 0

Skills gained which would eventually help my engineering career: even stronger self-starter skills, ability to focus on the task-at-hand and remove distractions

Hollywood dreams

I quit my stable job with great benefits while my parents were vacationing overseas and broke the news to them over the phone the day they returned. I do not recommend this strategy for breaking news like this. It did not go over well, to say the least.

After arriving in LA, I found a job working as a graveyard shift Front Desk Agent at a hotel on the Sunset Strip. My plan was to work nights, hit the gym in the morning, and audition for acting roles in the afternoon. This plan turned out to be very naive. I auditioned for a grand total of zero roles as I had failed to take sleep into consideration. I never really got accustomed to the overnight shift and felt like a zombie most days.

I made the decision to move back to my hometown in late 2008 just as the economy was collapsing.

Total lines of code written by age 26: 0

Skills gained which would eventually help my engineering career: the ability to fight through adversity, communication skills, “debugging” (in this case in support of solving hotel guest issues)

Return to the East Coast

I moved back to the East Coast at the very end of 2008 when the economy had hit rock bottom. It took me almost a full year to find another job. In hindsight, I wish I had begun learning to code at this point but it never crossed my mind.

I worked as a Data Analyst on a temporary contract for a little over a year. I had no benefits: no healthcare, zero vacation days, no opportunity to advance. Thankfully, my wife encouraged me to pursue a career in actuarial science. I had a solid math background and actuarial careers pay well so I started studying!

Total lines of code written by age 29: 0

Skills gained which would eventually help my engineering career: analytical skills

Avoiding risk

I passed the first two actuarial exams on my own which led to an opportunity to work at a local insurance company. This was a huge step up from my prior temp role. This position is where I began to dabble in some “programming” in a way. Most of my days were spent in massive Microsoft Excel files updating and improving macros. I found that I really enjoyed this work although it still felt fairly tedious.

I struggled mightily with the third actuarial exam and ended up transitioning off of the exam track and into an actuarial technician role. This role afforded me the opportunity to begin working with SQL Server. I took to this from day one and had a lot of fun learning SQL.

Total lines of code written by age 32: 0 (unless you count Excel macros and SQL)

Skills gained which would eventually help my engineering career: “programming” Excel macros, SQL

Embracing risk

Around this same time, one of my best friends from high school and I decided to work on a health and fitness startup. The basic idea was to connect the millions of health and fitness-related photos shared on social media (meals, supplements, workouts, etc.) to health and fitness companies. You can think of it as a healthy living rewards platform. We called it ConquerFit.

We outsourced development of the ConquerFit app to a local dev team and they delivered exactly what we wanted for our MVP. We quickly realized, however, that our friends and family funding had been blown through and we had a lot of features that needed to be added to the app before it was ready for general public release.

I decided to teach myself to code in order to build the “v2” version of our app.

I dove in head first starting with Codecademy which I found to be an excellent first resource. After working through all of the JavaScript, HTML, CSS, and SQL material on Codecademy, I moved on to Treehouse.

I felt confident at this point and began hacking on some small sample projects. I cannot stress enough how important it is to begin working on an actual project early on in your learning journey. Working through tutorials is one thing, building an app is quite another. You’ll quickly get familiar with git and GitHub, npm, browser dev tools, and much more.

The sample project I spent most of my time on was something I called “MobSeen”. This application focused on sports events and allowed users to view Instagram photos shared in and around sporting events in near real-time. In order to build this app, I needed to gain a deeper understanding of Node.JS, AngularJS and setting up and managing a database. This turned out to be a great learning experience!

I loved the process of learning, building, stumbling, learning some more, and repeating over and over again. What I found that I did not love was running a startup and thinking about fundraising, marketing, accounting, etc. ConquerFit would fade away but my newfound passion for web development would propel my career forward.

Total lines of code written by age 32: many 😁

Skills gained which would eventually help my engineering career: HTML, CSS, JavaScript, git, GitHub, npm, browser dev tools, debugging

Given a chance

I was very hesitant to apply for software engineering jobs at first as I never quite felt “ready”. Thankfully, my wife urged me to go for it and I followed her advice. I was able to get on the Hired platform in the spring of 2015. I originally was only interested in jobs in Central Massachusetts as I wanted to avoid a commute. My recruiter, however, convinced me to expand my search area to Boston and I am so thankful that I did. I interviewed with a half dozen companies before receiving and accepting an offer from Circle.

My first role in this field was as a Software Engineer on the internal tools team at Circle. I was, and continue to be, incredibly grateful to the team at Circle for giving me a chance. I had an awesome manager and was surrounded by an intelligent, hard-working and collaborative team from day one. I can’t say enough about how comfortable they made me feel and how much I learned over those first couple of weeks, months, and years in the industry.

Total lines of PRODUCTION code written by age 34: many 😁

Giving back

I have spent the last eighteen months in Tech Lead/Engineering Manager roles which have allowed me to further improve my communication, prioritization, planning and management skills. I am focused on giving back to more junior developers and career-changers at this point through blogging, speaking at conferences, building video courses, and mentorship.

Take it from me: you are not too old to start coding, and your seemingly unrelated career path to this point will help you to be a better engineer in the long run. Start learning, start building, and never stop asking questions! In fact, feel free to reach out to me @mattdionis or mattdionis@gmail.com with any and all questions.

Resources that have helped me (and could help you)

Learning platforms

• Codecademy (solid for beginners)
• Treehouse (great next step after Codecademy)
• Pluralsight (more advanced, deep dives into frameworks/libraries)
• Egghead.io (awesome JavaScript content)

Instructors/bloggers

• Samer Buna (especially love his Node.JS material)
• Dan Abramov (incredible deep dives into React)
• The Apollo GraphQL blog (great for beginner and experienced GraphQL devs alike)

Twitter follows

• Sarah Drasner (animations, VueJS, and so much more)
• Shirley Wu (data visualization awesomeness)
• Nadieh Bremer (⬆️ ditto)
• Shawn Wang (JAMstack!)
• John Papa (Angular!)

Podcasts

• React Podcast
• React Round Up
• Undefined
• Fullstack Health

Good luck!!! 👨‍💻

Never Too Late to Learn: My (meandering) path to a career in software engineering was originally published in ExtendNode’s Blogs for Entrepreneurs on Medium, where people are continuing the conversation by highlighting and responding to this story.

CodeSandbox is an awesome online code editor for spinning up and testing out new ideas quickly, sharing demo apps, collaborating, and even for getting larger projects started before moving them over to GitHub or another source control option.

Personally, I have used CodeSandbox to write both server-side (Node.js) and client-side (React) code. It’s my go-to choice for testing out new libraries (URQL), frameworks, and features (React Hooks). I’ve also used multiple CodeSandboxes like Legos and pieced them together. The best example of this is my Apollo Federated Gateway which links to a Location Service and a Weather Service. I then call this Gateway from my Apollo/URQL side-by-side React CodeSandbox. That’s four CodeSandboxes successfully working together! I like this approach because it allows anyone interested in learning about a separate piece of the stack to view, fork, and hack on just that isolated portion of code.

CodeSandbox has many more options and features than you might guess at first glance. In this post, we will dive into some of the more powerful features of this awesome tool!

Embedding

CodeSandboxes can be embedded in other sites so that users can view and play around with your sandbox. The quickest way to share a CodeSandbox project is to click on the “Share” button and choose one of the sharing options that appear in the lower right of the modal. However, there are about a dozen configuration options that you’ll want to become familiar with in order to customize your embeds.

Options

Appearance

There are about a half dozen appearance options that you can tweak.

The view option determines the default view of the embed and can be one of “editor”, “split”, or “preview”. If you do not explicitly set this option it defaults to “split” for large screens or “preview” for smaller screens. If you want to show off a very visual sandbox, then “preview” is probably the way to go. Otherwise, “editor” is probably the best option. With limited screen real estate in an embed, I have found “split” to not often be a great choice.

The autoresize option is Medium-specific and automatically resizes the embed to the content. This option is off (0) by default but can be turned on by passing 1 to autoresize instead.

The hidenavigation option allows you to hide the navigation bar above the sandbox preview which shows the URL. This option defaults to “off” (0) but I often set it to 1 as I don’t find the navigation bar necessary in an embed.

Next up is the expanddevtools option which determines whether the devtools console is open (1) or closed (2). This option defaults to closed which is typically what you would want.

The moduleview option evaluates the file which is currently open in the editor. This option defaults to false (0) but if you have a use case for this you can set it to 1 to turn it on.

The previewwindow option allows you to choose what appears in the preview window if view is set to “split” or “preview”. This option defaults to “browser” but you can also set it to “console”, to display the devtools console, or “tests”, to display your test results.

Finally, the fontsize option allows you to set the, you guessed it, font size in px. This option defaults to 14.

Sandbox Options

There are also a few sandbox options that you can configure to your liking.

First off, there’s the codemirror option which is set to false (0) by default which means that the Monaco editor will be used. If you want to reduce your embed size significantly, you can set this to 1 to use the CodeMirror editor instead. This can be a nice performance optimization for your embed if you’re OK with using CodeMirror.

The next option in this section is eslint which is false (0) by default. If you want to enable ESLint, you can simply set this option to 1, but be aware that this will increase your embed size significantly.

Finally, the module option determines which module to open by default. This defaults to your sandbox’s entry path, but you can set it to whichever module you would like. You can even show multiple modules as tabs by entering a comma-separated list.

Other Options

The initialpath option defaults to / but you may set it to any valid string to show a different path on load.

The editorsize option allows you to set the editor size as a percentage and defaults to 50.

The forcerefresh option forces a full refresh after every edit and defaults to false (0).

If you have the codemirror option set to 1, you can pass a comma-separated list of line numbers to the highlights option to highlight lines of code.

The runonclick option allows you to only load the preview when the user chooses to. This option is set to false (0) by default.

Finally, the verticallayout option allows you to choose whether to display the editor and preview vertically (1) or horizontally (0, default) when view is set to “split”.

Example embeds

Let’s briefly walk through a couple of examples of embeds using the options discussed above.

In this first embed, I am aiming to focus on the code and also ensure the embed is as performant as possible. I, therefore, choose the editor-only view (view=editor) and increase the font size to 20 (fontsize=20). I also set codemirror to 1 to ensure a lighter weight embed. The resulting embed appears below.

In this next embed, I aim to show as much code as possible while keeping it readable, side-by-side with the resulting UI. To accomplish this, I set module to the file that I’m concerned with, /src/components/SettingsComponent.jsx, and I set fontsize to 12 in order to fit more code on the screen. The default view is “Editor + Preview” although you’ll notice that on smaller screens this defaults to just show the preview. Users can click the split screen icon to show the code side-by-side with the preview. The resulting embed is shown below.

Now that you know a bit more about embed options, make sure to tweak them to your liking the next time you embed a CodeSandbox project!

Importing and Exporting projects

CodeSandbox has some great tools both for importing existing projects into CodeSandbox and for exporting projects to GitHub.

CodeSandbox CLI

CodeSandbox has a CLI! Confession time: I was not aware this existed until a few days ago. To install the CodeSandbox CLI globally, run:

npm install -g codesandbox

Once the CLI is installed, you can export a project to CodeSandbox by running codesandbox followed by the directory you want to export. For example, if you are currently in your project’s top-level directory, simply run codesandbox ./.

This is a very convenient feature if you want to quickly share a local project with a broader audience. But what if you find yourself in the opposite situation? You have a CodeSandbox project which you would like to get under source control in GitHub. There is a CodeSandbox feature to cover this situation as well!

GitHub Integration

The CodeSandbox GitHub integration allows you to import any public GitHub repository and also to export any CodeSandbox project to GitHub!

Importing

To import a GitHub repo into CodeSandbox simply grab the URL of the repo and paste it into the CodeSandbox “Import from GitHub” feature. After a few seconds, you’ll have a copy of your project in CodeSandbox!

Exporting

Exporting to GitHub is also possible. Simply click on the GitHub tab within your sandbox, enter the desired repo name, and click “Create Repository”!

Live Collaboration

CodeSandbox has a feature which makes it easy to collaborate on a sandbox with others in real-time! As they describe it, “it’s like Google Docs, but for your code”.

How to “Go Live”

To go “live”, you simply click on the Live tab and then click “Go Live” to generate a URL which others can use to join your live session. The CodeSandbox team prepared a great demo of this feature which you can view below.

Using “Classroom Mode”

Classroom Mode allows you to decide who can edit the sandbox during a live session. This is helpful if you are teaching and want everyone to be able to work with the same sandbox but only yourself, or a limited number of people, to actually be able to edit the sandbox.

Testing

CodeSandbox has native integration with Jest Tests for running tests! You simply need to create files which end with one of the following: .test.js, .spec.js, .test.js(x), or .spec.js(x).

Deploying

When you are ready to deploy a sandbox, you have two options: Zeit and Netlify.

To deploy using Zeit Now you will first need to create a Zeit account and log into it.

On the other hand, the Netlify integration allows you to deploy a sandbox even if you do not yet have a Netlify account. The following templates are available for Netlify deploys:

• React
• Vue
• Preact
• Nuxt
• Parcel
• Static
• CxJS
• Styleguidist
• Typescript Variants of React and Parcel
• Gatsby

Takeaways

I hope you now have a better understanding of just how flexible and powerful CodeSandbox can be. Now get to building!

Why are Hooks so exciting?

React Hooks were introduced in the late fall of 2018 and officially made available in a stable release in React 16.8. I watched the React Conf talks introducing React Hooks but must admit that I didn’t “get it” at first. Sure, I understood the basics of hooks but I couldn’t quite grasp the benefits. Luckily, there are a ton of resources out there discussing hooks so I dove in and devoured as much content as I could. This post is meant to clearly summarize my findings and explain why I’m now a huge fan of hooks. Let’s kick things off by discussing how hooks address some common React inefficiencies.

Sharing stateful logic between components

“Hooks let us organize the logic inside a component into reusable isolated units” — Dan Abramov

I really like the above quote from Dan Abramov. In the past, pre-hooks, the code in React components was often split up by lifecycle method rather than concern. Business logic was mixed together and difficult, if not impossible, to separate. Hooks allow us to organize, isolate, and reuse this logic. As my headline image makes clear, when I think of hooks I think of velcro. Just like velcro straps, hooks can easily be attached, detached, and moved around.

The below tweet from Sunil Pai is also a nice way to visualize this idea.

Sunil Pai on Twitter

ok so - I took dan's classes/hooks code from react conf, blacked out the 'unnecessary' bits, then colour coded bits by 'concern'. so much nicer. the effect is amplified in more complex components, where concerns are split and mixed across lifecycle methods.

Let’s take a closer look at Sunil’s use of hooks in this example. We can clearly see the isolation of concerns in the above code. Theme, name, and width are separated out into their own logical units. However, if you are new to hooks, the above code may bring up more questions than answers. How can we get away with calling useState and useEffect multiple times in the same component? Why does the second call to useEffect return a function but the first does not? How can I ensure useEffect only runs on initial render or when a certain variable changes? By the end of this post, all of these questions and more will be answered.

“They’re not a way to share state — but a way to share stateful logic.” — Dan Abramov

To me, this is the most important concept to grasp. We now have a way to share stateful logic. This allows us to isolate and reuse this logic rather than repeating it all over the place.

Managing state in components

Prior to the introduction of hooks, we needed to spin up a class component if we needed to work with state. State was then managed through one object which could often grow to contain many stateful properties.

Continuing to work with the above example, this is how a typical pre-hooks stateful component would handle state:

this.state = {
  name: "Harry",
  surname: "Potter",
  width: window.innerWidth
}

...

this.setState({ name });
this.setState({ surname });
this.setState({ width: window.innerWidth });

You can see how separate concerns (name, width) are lumped together in the this.state object. You’ll also notice how we need to call this.setState any time we need to update a stateful property.

Now let’s take a look at this same component updated to make use of hooks:

let [name, setName] = useState("Harry");
let [surname, setSurname] = useState("Potter");
useEffect(() => {
  document.title = name + " " + surname;
});

let [width, setWidth] = useState(window.innerWidth);
useEffect(() => {
  let handleResize = () => setWidth(window.innerWidth);
  window.addEventListener("resize", handleResize);
  return () => {
    window.removeEventListener("resize", handleResize);
  };
});

You’ll notice a clear separation of concerns and explicit function names for updating each stateful property (setName, setSurname, setWidth) rather than multiple calls to this.setState. You’ll also notice that the lifecycle methods have disappeared. Let’s take a closer look at that change next.

Lifecycle methods

In the original code of the example we’ve been working with, three different lifecycle methods are used: componentDidMount, componentDidUpdate, and componentWillUnmount:

componentDidMount() {
  window.addEventListener("resize", this.handleResize);
  document.title = this.state.name + ' ' + this.state.surname;
}
...
componentDidUpdate() {
  document.title = this.state.name + ' ' + this.state.surname;
}
...
componentWillUnmount() {
  window.removeEventListener("resize", this.handleResize);
}

You’ll notice a couple less than ideal aspects of this code. Separate concerns are lumped together within componentDidMount: listening to the “resize” event and setting document.title. Furthermore, there is repeated code for setting document.title. Are these major issues? No, not at this stage. However, as an application grows you will inevitably have more concerns mixed together in lifecycle methods and more repeated code between these methods. We can do better!

Here is the code which replaces the above lifecycle methods when you’re working with hooks:

useEffect(() => {
  document.title = name + " " + surname;
});

...

useEffect(() => {
  let handleResize = () => setWidth(window.innerWidth);
  window.addEventListener("resize", handleResize);
  return () => {
    window.removeEventListener("resize", handleResize);
  };
});

The first call to useEffect covers the componentDidMount and componentDidUpdate calls from above. The second call to useEffect actually covers componentDidMount, componentDidUpdate, and componentWillUnmount. We will discuss details about how to use useEffect later in this post.

Higher-order components and render props

“Unlike patterns like render props or higher-order components, Hooks don’t introduce unnecessary nesting into your component tree.” — Dan Abramov

Higher-order components allow us to reuse component logic and are possible thanks to React’s compositional nature. The problem is that they lead to what some have called “wrapper hell”. If you’ve ever worked in Node.js this can be compared to “callback hell”. Below is a contrived example to visually highlight what “wrapper hell” means:

const EnhancedTodoComponent = compose(
  withConfirm(),
  withErrorBoundary(),
  withAutoBinding()
)(TodoComponent);

export default EnhancedTodoComponent;

Obviously, the above can get tedious but the real pain comes with debugging as you’ll often see output like this in React Dev Tools (and this is tame compared to some components which are wrapped in many more higher-order components):

withConfirm(withErrorBoundary(withAutoBinding(ToDoComponent)))
withErrorBoundary(withAutoBinding(ToDoComponent))
withAutoBinding(ToDoComponent)
ToDoComponent

We can often run into similar situations with the render props pattern. Here is an example of this pattern from the Apollo docs in relation to the Query component:

const Dogs = ({ onDogSelected }) => (
  <Query query={GET_DOGS}>
    {({ loading, error, data }) => {
      if (loading) return "Loading...";
      if (error) return `Error! ${error.message}`;

      return (
        <select name="dog" onChange={onDogSelected}>
          {data.dogs.map(dog => (
            <option key={dog.id} value={dog.breed}>
              {dog.breed}
            </option>
          ))}
        </select>
      );
    }}
  </Query>
);

While this example only includes one level of nesting, you can imagine the “wrapper hell” we will encounter in more complex components with many levels of nesting.

Using hooks in place of higher-order components and render props can definitely clean up your component tree and make debugging a bit easier.

How are Hooks implemented (at a high level)?

I often find myself asking “how” when learning new technical concepts. I don’t feel like I truly grasp a concept until I understand how it is implemented. I’m not necessarily looking for a line-by-line analysis of source code, but a high-level understanding of implementation can go a long way toward wrapping one’s head around a new concept.

There are two JavaScript features you will need to understand deeply if you want to grasp how hooks work: closures and arrays.

Closures

Shawn Wang (Swyx) does an excellent job discussing closures and how they relate to hooks in “Deep Dive: How do React hooks really work?”. I highly encourage you to bookmark that link and read through Shawn’s post. Below is his possible implementation of the React useState hook through closures:

const MyReact = (function() {
  let _val // hold our state in module scope
  return {
    render(Component) {
      const Comp = Component()
      Comp.render()
      return Comp
    },
    useState(initialValue) {
      _val = _val || initialValue // assign anew every run
      function setState(newVal) {
        _val = newVal
      }
      return [_val, setState]
    }
  }
})()

// all credit to Shawn Wang (https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-react-hooks-really-work/)

You can see that _val is declared outside of the scope of the component and closed over. This setup allows _val to successfully be updated by the useState method. This setup also ensures _val is “reset” on future renders.

Arrays

The first “rule of hooks” which we’ll discuss below basically states, “only call hooks at the top level…to ensure that hooks are always called in a consistent order”. This should trigger thoughts of arrays as clearly the “index” of the hook matters a great deal. Rudi Yardley does an excellent job discussing how hooks rely on arrays in “React Hooks: Not magic, just arrays” and I highly recommend giving it a read. At a high-level, the below code shows his “naive” implementation of useState:

let state = [];
let setters = [];
let firstRun = true;
let cursor = 0;

function createSetter(cursor) {
  return function setterWithCursor(newVal) {
    state[cursor] = newVal;
  };
}

// This is the pseudocode for the useState helper
export function useState(initVal) {
  if (firstRun) {
    state.push(initVal);
    setters.push(createSetter(cursor));
    firstRun = false;
  }

  const setter = setters[cursor];
  const value = state[cursor];

  cursor++;
  return [value, setter];
}

// all credit to Rudi Yardley (https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e)

You can clearly see the use of multiple arrays in the above implementation: one for state and one for setters. Obviously, the order in which you declare hooks is very important. Messing with this order could result in mismatches between state values and setters and what you expect them to be.

Why Follow the Rules?

There are two rules that we must follow when using React hooks. Like my three-year-old daughter, my first question when presented with new rules is “why”. So let’s discuss…

Only call hooks at the top level

Hooks should only be called at the top-level of your React function components. This means you should not be calling hooks inside conditionals, loops, or nested functions. Following this rule ensures that hooks are always called in a consistent order. React relies upon hooks being called in this consistent order.

Let’s take a look at a basic example showing how a conditional check could break usage of hooks. First, a valid use of hooks:

const [firstName, setFirstName] = useState('Matt');

const [location, setLocation] = useState('Los Angeles');

No conditionals, loops, or nested functions wrapping useState. We’re in good shape! 👍

However…

if (!defaultName) {
  const [firstName, setFirstName] = useState('Matt');
}

const [location, setLocation] = useState('Los Angeles');

This violates the first rule of hooks. If defaultName always resolves to false then we’d be “safe”, but there’s no guarantee of that. In cases where defaultName is truthy the useState('Los Angeles') hook will come first and functionality will be busted. 👎

If we want to run an effect conditionally, we can put that condition inside our Hook like so:

const [firstName, setFirstName] = useState(() => {
  return defaultName || 'Matt';
});

const [location, setLocation] = useState('Los Angeles');

This is obviously a contrived example, but the point is that you can move your conditional logic inside the hook.

Only call hooks from React functions

Hooks should only be called within React function components or inside custom hooks. Do not call hooks inside regular JavaScript functions. As the React docs state, “by following this rule, you ensure that all stateful logic in a component is clearly visible from its source code”.

ESLint plugin

Following rules can be hard but thankfully there is an ESLint plugin available which enforces the two above rules, eslint-plugin-react-hooks.

If you don’t already have ESLint installed and configured in your project, I highly recommend doing so. After this, simply run:

npm install eslint-plugin-react-hooks --save-dev

or

yarn add eslint-plugin-react-hooks -D

Then add the following to your ESLint config:

{
  "plugins": [
    // ...
    "react-hooks"
  ],
  "rules": {
    // ...
    "react-hooks/rules-of-hooks": "error", // Checks rules of Hooks
    "react-hooks/exhaustive-deps": "warn" // Checks effect dependencies
  }
}

Note: eslint-plugin-react-hooks has been included in create-react-app since v3.0.0! 🎉

The useSomething naming convention is how the linter plugin is able to find bugs in the code using Hooks. You should always name your hooks starting with use....

Built-in React Hooks

useState

In the past, our only choice when working with state was to spin up a class component and use this.setState to update state. The useState hook allows us to manage state in function components. Basic usage looks like the following:

[count, setCount] = useState(0);

We use array destructuring ([count, setCount]) to return a pair from our useState invocation. count will be initialized to 0 as that is the value we passed to useState. The update function, setCount in this case, is similar to this.setState in a class, except it does not merge the old and new state together.

If the initial state is the result of an expensive computation, you may provide a function instead, which will be executed only on the initial render. That scenario would look like this (taken from the React docs):

const [state, setState] = useState(() => {
  const initialState = someExpensiveComputation(props);
  return initialState;
});

Furthermore, if you would like to take the previous state into account when computing the new state, you can pass a function to the setState method and this method will receive the previous state as an argument:

<button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>

React assumes that if you call useState many times, you do it in the same order during every render.

useState is a solid solution if you only have a few state properties to manage. useReducer is the better choice once you have many state properties. We will discuss this next.

useReducer

useReducer is an alternative to useState and is preferable when you have a lot of state to work with. The signature of useReducer looks like this:

const [state, dispatch] = useReducer(reducer, initialArg, init);

There are two ways to seed useReducer with an initial state. The simplest approach is to pass the initial state as the second argument like so:

const [state, dispatch] = useReducer(
  reducer,
  {count: initialCount}
);

The other option is to pass an init function as the third argument like this:

function init(initialCount) {
  return {count: initialCount};
}

const [state, dispatch] = useReducer(reducer, initialCount, init);

This approach is handy if you want to extract the logic for calculating the initial state outside the reducer. This also makes it easier to implement a “reset” feature.

Below is a very basic example of useReducer being used to set and update the state of a NumberManipulator component:

const initialState = { num: 2 };

function reducer(state, action) {
  switch (action.type) {
    case 'double':
      return { num: state.num * 2 };
    case 'half':
      return { num: state.num / 2 };
    case 'square':
      return { num: state.num * state.num };
    default:
      throw new Error();
  }
}

function NumberManipulator() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Number: {state.num}
      <button onClick={() => dispatch({type: 'double'})}>double</button>
      <button onClick={() => dispatch({type: 'half'})}>half</button>
      <button onClick={() => dispatch({type: 'square'})}>square</button>
    </>
  );
}

If you return the same value from useReducer as the current state, React will bail out without rendering the children or firing effects. This is a nice performance optimization feature (note: for much more on optimizing performance with React Hooks, check out this post by Subhan Naeem).

useEffect

useEffect can be thought of as a replacement for lifecycle methods (componentDidMount, componentDidUpdate, componentWillUnmount, etc.).

The most basic use of useEffect looks like this:

useEffect(() => {
  document.title = 'Welcome to ' + props.name;
});

Super simple, right? Actually, there is a lot more to useEffect than it appears at first glance.

The above code will work, but it will also fire on every single render. We probably don’t want this to be the case. We would prefer that this effect only runs when props.name changes. We can accomplish this by passing an optional second argument to useEffect. This second argument is an array of dependencies and the effect will now only fire when one of the dependencies in this array changes. Let’s update our effect to only fire when props.name changes:

useEffect(() => {
  document.title = 'Welcome to ' + props.name;
}, [props.name]);

Great! Now, what if we only wanted our effect to fire on the initial render. Maybe we are confident that props.name will never change and we want to ensure our effect only fires once. To accomplish this, we also lean on the optional second argument. In this case, we pass an empty array. This tells useEffect that there are no dependencies and this effect only needs to be called once:

useEffect(() => {
  document.title = 'Welcome to ' + props.name;
}, []);

While most effects do not require cleanup, some, such as subscriptions, do. So how do we handle cleanup? Do we need to rely on a lifecycle method, componentWillUnmount, after all? No! You can return a function from the function you passed to useEffect and handle any cleanup logic there. This may sound confusing, but this example from the React docs should help:

useEffect(() => {
  const subscription = props.source.subscribe();
  return () => {
    // Clean up the subscription
    subscription.unsubscribe();
  };
});

This approach can also be used for effects which include event listeners.

Additional built-in React hooks

There are about a half dozen additional built-in hooks which we will not dive into here but you can learn about on your own through these links to the official React docs:

• useMemo
• useContext
• useCallback
• useRef
• useImperativeHandle
• useLayoutEffect
• useDebugValue

Hooks in the wild

I have found that the best way to get comfortable with hooks is to use custom hooks available in libraries I already depend upon. I can then, for example, understand how a hook replaces functionality I previously depended upon through a higher-order component or render prop.

Apollo GraphQL hooks

I ❤️ working with Apollo, so the first custom hooks I utilized were useQuery and useMutation from @apollo/react-hooks. Here is an example CodeSandbox:

Apollo GraphQL React-hooks example - CodeSandbox

Here’s the use of useQuery in isolation:

I pass a GraphQL query to useQuery and it returns an object with a loading property and a data property. I use loading to display a basic loading indicator. Once data is available, I iterate over data.teams to render my component!

Here is an example showing the use of useMutation:

I pass a GraphQL mutation to useMutation as the first argument. Within the second argument, I pass optional variables. In this case, I need to pass id for this mutation to work. I also added an optional update function which updates the cache on a successful mutation. Prior to hooks, Apollo followed the render props pattern. I had a very easy time translating my legacy use of render props with these custom hooks. Plus, my code is now easier to read and maintain, in my opinion.

URQL hooks

I also find that looking at the source code behind custom hooks greatly helps me understand how to go about implementing my own custom hooks. I recently began looking through the custom hooks within the URQL library from Formidable. Below you can see how URQL utilizes the built-in useRef and useMemo hooks to build their useRequest custom hook:

I encourage you to read through the URQL hooks source code to gain a deeper understanding of implementing custom hooks!

Hooks outside of React

While hooks were originally introduced for React, there is no reason they cannot be implemented for other frameworks and also in vanilla JS, and indeed they already have been!

VueJS hooks

I’m not going to get into the current controversy in the VueJS community, but I will point out that there is an experimental library for using React-style hooks in Vue. This repo was spun up by Evan You himself.

There is also an excellent post by Sarah Drasner which discusses why hooks may be beneficial for Vue, “What Hooks Mean for Vue”!

TNG-Hooks

Hooks can also be used in vanilla JavaScript without a framework like React or Vue thanks to the TNG-Hooks library created by Kyle Simpson. In order to effectively use hooks, we need functions which are both stateful and effectful, similar to React function components. Within TNG-Hooks, these functions are referred to as Articulated Functions and are generated by wrapping functions in the TNG hooks-context like so:

[renderUsername, onClickUsername] = TNG(renderUsername, onClickUsername);

The first example from the TNG-Hooks README should make you feel comfortable right away:

Other than wrapping functions in TNG, this all looks very familiar after going over React hooks. useState works how you would expect it to!

Adoption Strategy

To enable Hooks, all of your React packages must be ≥ 16.8.0. Remember that hooks can only be added to function components or used within other custom hooks. While we’re in the early days, the goal is for hooks to cover all use cases for classes as soon as possible, according to the React team. You can incrementally begin adding hooks to your existing apps. You may also begin replacing uses of higher-order components and render props with hooks, although full-scale app rewrites are neither necessary nor encouraged as the introduction of hooks will not “break” legacy solutions. Finally, install eslint-plugin-react-hooks to ensure you are consistently following the rules of hooks!

Takeaways

I hope you learned something from this (long) post and feel at least a bit more confident about working with hooks. Please reach out to me with any feedback as I’m sure there are things I have overlooked or could have explained better. Thank you!

Interested in GraphQL or looking for a lightweight state management solution? Check out “Move Over Redux”.

Get Hooked: Hooks in React and Beyond was originally published in Circle Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently joined the Medium Partner Program and soon after I stumbled upon the “Gift a membership” feature in Medium. I immediately recognized a potential opportunity to give back to Medium readers. For $50, an annual Medium membership can be gifted to a reader.

As a point of reference, a recent post of mine which had decent readership earned $34.25 in its first week in the Partner Program. One week’s worth of earnings from this single post can almost fund an annual membership for a reader. My personal plan going forward is to produce more consistent, compelling content on Medium both to hopefully inspire and educate others and to fund annual membership gifts.

My goal is to gift one annual membership each week going forward. This is exciting but what would make it exponentially more impactful is if other writers (most with far greater audiences than I) joined this initiative. Together we could gift hundreds of annual memberships every single week! Medium continues earning revenue, writers broaden their audience, and readers who otherwise could not afford this membership can finally have one.

One question may be, why not just offer your content for free? I actually do offer mine for free on my personal blog but that site has far fewer potential readers than Medium and virtually zero discoverability features. Furthermore, writers put time, energy, and emotion into their posts and I feel like compensation is earned. It is certainly not free money.

Please tag your favorite writers so that we can quickly make this vision a reality. I would love to build up enough momentum that Medium takes notice and joins forces with us to formalize this program and reach as many readers as possible!
Thank you!

Giving Back: Medium Partner Program + membership gifting was originally published in Adventures in Consumer Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

On the Internal Tools team at Circle, we recently modernized a legacy PHP app by introducing React components. Just a handful of months after this initiative began we have close to one-hundred React components in this app! 😲

We recently reached a point where we found ourselves reaching for a state management solution. Note that it took many months and dozens of components before we reached this point. State management is often a tool that teams reach for well before they need it. While integrating a state management solution into an application no doubt comes with many benefits it also introduces complexity so don’t reach for it until you truly need it.

Speaking of complexity, one complaint about the typical “go-to” state management solution, Redux, is that it requires too much boilerplate and can be difficult to hit-the-ground-running with. In this post, we will look at a more lightweight solution which comes with the added benefit of providing some basic GraphQL experience for those who choose to use it.

On the Circle 🛠 team, we know that our future stack includes GraphQL. In fact, in the ideal scenario, we would have a company-wide data graph at some point and access and mutate data consistently through GraphQL. However, in the short-term, we were simply looking for a low-friction way to introduce GraphQL to a piece of the stack and allow developers to wrap their heads around this technology in a low-stress way. GraphQL as a client-side state management solution using libraries such as apollo-client felt like the perfect way to get started. Let’s take a look at the high-level implementation of a proof-of-concept for this approach!

Configuring the client

First, there are a number of packages we’ll need to pull in:

yarn add @apollo/react-hooks apollo-cache-inmemory apollo-client graphql graphql-tag react react-dom

Below you’ll find index.js on the client in its entirety. We’ll walk through the client-side schema specific pieces next:

First, we define typeDefs and resolvers.

The AppBarColorSetting type will have required id, name, and setting fields. This will allow us to fetch and mutate the app bar’s color through GraphQL queries and mutations!

type AppBarColorSetting {
  id: Int!
  name: String!
  setting: String!
}

Next up, we define the Query type so that we can fetch the appBarColorSetting:

type Query {
  appBarColorSetting: AppBarColorSetting!
}

Finally, you guessed it, we need to define the Mutation type so that we can update appBarColorSetting:

type Mutation {
  updateAppBarColorSetting(setting: String!): AppBarColorSetting!
}

Finally, we set up our client. Often, you will find yourself instantiating ApolloClient with alink property. However, since we have added a cache and resolvers, we do not need to add a link. We do, however, add a couple of properties that may look unfamiliar. As of apollo-client 2.6, you can set an assumeImmutableResults property to true to let apollo-client know that you are confident you are not modifying cache result objects. This can, potentially, unlock substantial performance improvements. To enforce immutability, you can also add the freezeResults property to inMemoryCache and set it to true. Mutating frozen objects will now throw a helpful exception in strict mode in non-production environments. To learn more, read the “What’s new in Apollo Client 2.6” post from Ben Newman.

const client = new ApolloClient({
  cache: new InMemoryCache({
    freezeResults: true
  }),
  typeDefs,
  resolvers,
  assumeImmutableResults: true
});

That’s it! Now, simply pass this client to ApolloProvider and we’ll be ready to write our query and mutation! 🚀

const TogglesApp = () => (
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>
);

Querying client-side data

We’re now going to query our client cache using GraphQL. Note that in this proof-of-concept, we simply define the initial state of our userSettings in a JSON blob:

Note the need to define the type with the __typename property.

We then define our query in its own .js file. You could choose to define this in the same file the query is called from or even in a .graphql file though.

The most important thing to notice about this query is the use of the @client directive. We need to add this to both the appBarColorSetting query as well as each of the id, name and setting fields as they are all client-specific. Let’s take a look at how we call this query next:

Note: we are using Material-UI in this app, but obviously the UI framework choice is up to you. 🤷‍♂️

Some bonus material: we are using the beta version of apollo/react-hooks here!

const { loading, data } = useQuery(APP_BAR_COLOR_SETTING_QUERY);

We show a basic loading indicator and then render the app bar with data.appBarColorSetting.setting passed into the color attribute. If you are using the Apollo Client Developer Tools, you’ll be able to clearly see this data sitting in the cache.

Mutating client-side data and updating the cache

You may have noticed this block of code in our App component. This simply alternates the value of setting based on its current value and passes it to our SettingsComponent. We will take a look at this component and how it triggers a GraphQL mutation next.

<SettingsComponent
  setting={
    data.appBarColorSetting.setting === "primary" ? "secondary" : "primary"
  }
/>

First, let’s take a peek at our mutation:

Again, notice the use of the @client directive for our client-side updateAppBarColorSetting mutation. This mutation is very simple: pass in a required setting string and update the setting.

Below you will find all the code within our SettingsComponent which utilizes this mutation:

The interesting piece of this code that we want to focus on is the following:

Here, we make use of the apollo/react-hooks useMutation hook, pass it our mutation and variables, then update the cache within the update method. We first read the current results for the APP_BAR_COLOR_SETTING_QUERY from the cache then update appBarColorSetting.setting to the setting passed to this component as a prop, then write the updated appBarColorSetting back to APP_BAR_COLOR_SETTING_QUERY. Notice that we do not update the data object directly, but instead make a clone of it and update setting within the clone, then write the cloned data object back to the cache. This triggers our app bar to update with the new color! We are now utilizing apollo-client as a client-side state management solution! 🚀

Takeaways

If you’d like to dig into the code further, the CodeSandbox can be found here. This is admittedly a very contrived example but it shows how easy it can be to leverage apollo-client as a state management solution. This can be an excellent way to introduce GraphQL and the Apollo suite of libraries and tools to a team who has little to no GraphQL experience. Expanding use of GraphQL is simple once this basic infrastructure is in place.

I would love to hear thoughts and feedback from everyone and I hope you learned something useful through this post!

If you found this post helpful, please 👏 for it to fund free Medium memberships for other readers! To learn more about this initiative, check out: “Giving Back: Medium Partner Program + membership gifting”.

Move Over Redux was originally published in Circle Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s set the scene: It’s a fall Friday evening and you have just been seated at a restaurant you have been excited to try, The Underfetching Farmhouse. The waiter brings over the menu and you immediately notice that it seems, well…sparse. In the middle of this sheet of white paper are four words: appetizers, entrees, drinks, dessert. Not wanting to embarrass yourself you decide to just “go with the flow”. Hey, maybe this is a new “hip and edgy” way to order. Play it cool. The waiter returns a few minutes later and you state that you are interested in appetizers, entrees, and drinks. The waiter nods in approval and heads off in a hurry. He returns with an appetizers menu then scoots off again. A minute later he is back again with a list of entrees. He runs back to his station yet again and then quickly returns with a drink menu. While progress has certainly been made, you are still rather underwhelmed with what has been provided to you. You now know what appetizers, entrees, and drinks are available, but that’s it. No descriptions, no prices. Turns out the waiter will have to make another roundtrip for the description of each menu item you are interested in and yet another for the price. Underfetching indeed! You’ve had enough and decide to leave and try another spot down the street.

You arrive at the second restaurant of the evening, The Organic Overfetch, ready to quickly order as you are now starving. When your waiter greets you, you explain your recent experience and the waiter giggles as he promises you will not run into the same frustration at this establishment. He leaves for what feels like an eternity and when he returns he places what appears to be a medium-sized novel on the table. You slowly open this book and realize it is the menu. There are categories, menu items, descriptions, ingredients, prices, nutritional information, images, chef biographies. Try as you may, you become lost in this menu and have a very difficult time finding the information you are interested in. In your frustration you storm out of this business as well.

As you reach the sidewalk you glance across the street and notice a new restaurant that you have been hearing a lot of chatter about. The GraphQL Cafe is beckoning and you decide to give it a try. You are quickly seated and the waiter asks you what information you would like on your menu. This seems like an odd question, but you play along. “I would like to see the name, description, and price for each of your appetizers, entrees, and drinks”, you say. Within seconds your waiter returns with a small menu matching exactly what you requested. You order and settle in for a relaxing dinner thinking, “this is the way it should be.”

If you’ve worked with REST APIs, you can surely relate to this poor diner’s experience at The Underfetching Farmhouse and The Organic Overfetch. As developers, we are constantly trying to balance how much data we return from our API endpoints. Do you provide just enough and then make the client call additional endpoints to get more details? Do you provide everything the client could possibly need in one giant data blob? Thankfully there is now another option. GraphQL solves both the underfetching and overfetching problems by allowing clients to ask for exactly what they need from the server. Want to see the name, description, and price for entrees? Just call your single /graphql endpoint with this simple, descriptive query:

query getMenu(category: String!) {
  menu(category: “entrees”) {
    name
    description
    price
  }
}

There are many more benefits and tons of exciting possibilities that GraphQL makes possible! This post is simply meant to point out two of the major issues that GraphQL solves and hopefully get you excited about digging deeper. To learn more about the technical “nitty-gritty” check out the GraphQL spec.🤓 For some awesome step-by-step tutorials about all things GraphQL, both server-side and client-side, check out HowToGraphQL. You may want to get started with GraphQL through a backend development framework. If so, check out Graphcool.😎 For an incredible suite of tools to help you optimize the apps you build with GraphQL, there is no better option than Apollo!🚀 Also, feel free to reach out to me on Twitter. I am always excited to talk all things GraphQL!😍

This is the fourth post in a series which dives into unit tests within the VueJS code base in order to gain a deeper understanding of how elements within the Vue ecosystem work. I recommend checking out the first post on v-show, second post on v-if, and third post on v-for before diving into this article.

Beyond alerting one to regressions in a code base, well-written unit tests read like simple sentences and help those working on a project to understand what individual features do. Unit tests can also serve as great templates for documentation if they are written well as they should describe what a feature does and how it reacts to different inputs.

The VueJS documentation is excellent, but recently I decided to dig even deeper and begin exploring the source code behind Vue! The first piece of the code base I visited was the tests directory. Most of you have surely heard of Test Driven Development (TDD). Well, in this series I would like to introduce you to Test Driven Learning (TDL). The idea is to begin reading through the unit tests of the framework or library you are using early in order to gain a deeper understanding of how individual features work. TDL also has a beneficial side-effect in that it will reinforce the benefits of writing unit tests in your own projects and reveal solid testing patterns.

‘v-text’ versus ‘v-html’ unit tests

In this third post in the series we will take a look at the v-text and v-html directives. The v-text unit tests can be found here and the v-html unit tests here, but we will be walking through them piece-by-piece below.

First up, v-text! The first test is very basic and simply tests that the string bound to the a data property is rendered as the element’s innerHTML. If you feel like this seems familiar it is because v-text works just like {{}} interpolation. <div v-text=”a”></div> renders the same output as <div>{{a}}</div>.

The next test is a bit more interesting as it reveals what happens when you pass HTML markup to v-text. It appears that v-text encodes HTML entities such as < and >.

The final block of tests shows how v-text behaves with several different value types. Booleans, arrays, objects, strings, numbers, and even spaces will be rendered as their string equivalents: “false”, “[]”, “{}”, “abc”, “123”, “ “, respectively. null and undefined are rendered as empty strings.

Let’s say we’re working on a project and find that we need to render HTML markup. We cannot rely on v-text as we have learned that it will encode this markup. Where do we turn? Another directive, aptly named v-html!

The first test below should look familiar as it is the exact same as the first test for v-text. This shows us that passing a basic string to v-html will render it the same as v-text or interpolation would.

The second test is more interesting and differs from v-text in an important way. When passed HTML entities, v-html will render them as plain HTML rather than encoding them. Note that the < symbol within the span is encoded properly as expected.

The next couple tests reveal other ways this directive can be used. HTML entities can be passed inline as well as inline in the DOM. The final block of tests is identical to the final block of tests for v-text and shows how different value types will be rendered.

‘v-text’ and ‘v-html’ docs

The v-text and v-html API docs sections should make complete sense to us now that we have studied the unit tests:

As I mentioned earlier, the VueJS docs are excellent, but I would argue that reading through the unit tests behind v-text and v-html taught us all that the docs reveal and more in just a couple minutes of reading! Also, as I mentioned, reading through the tests taught us how unit tests should be written and how thorough they should be. Writing similar tests for features within your own apps should become a priority for you and your team!

Next up

In the next post, to be published soon, we will take a deep dive into the v-class unit tests!

Previous posts

• v-show
• v-if
• v-for

If you enjoyed this post please hit the little 💚 below to let me know you’d like more of this material! Thanks! 🤓

Interested in building the future of money at Circle? We’re hiring!

VueJS unit tests as a learning tool: v-text versus v-html was originally published in Vuefinder on Medium, where people are continuing the conversation by highlighting and responding to this story.