Announcements

I know its been a while. Between fulfilling client obligations and meeting deadlines, its been hard to stay on the content marketing treadmill. But I’m back and by the grace of God, I will continue to stay on the content engine for the foreseeable future. With that being said, my current plan is to start a skool community where I will pour most (if not all) of my paid content inside. The goal is to have paid subscribers who will have access to courses and products I create (think Netflix but for education). I also want this community to be a place for accountability. For example, a lot people know they should go to networking events but probably don’t! To start, I will start posting sections from an e-book I’m currently working on called The Software Developer’s Guide to Freelancing. This guide will have strategies and tactics for managing clients, communicating to clients and vetting clients as a Freelance Software Developer. So without further ado, here’s chapter one of the e-book.

Chapter 1- Finding Good Clients

Chapter one is not about pricing. It’s not about proposals. It’s not about contracts. It’s about discovery. And not technical discovery. It’s about discovering the client. Before you ever write a line of code, you need to understand who you are building for. The wrong client will waste your time, never pay you, scam you out of personal data, and have unreasonable expectations. The right client will respect you, take communication seriously, and pay you on time. The following sections will give you insight on what too look for in a good client and how to look for it in the wild!

What to look for in clients

In this section, I’m going to walk you through how I filter clients not based on theory, but patterns I’ve observed while working with real clients. Over time, I realized my best clients shared common traits. These were not random. They were patterns. Here were the patterns I noticed:

1. Easy to communicate with

One of the first serious clients I landed through LinkedIn was with a company called Ghost Creativ. Ownership may have changed since then, but at the time they brought me in for a React and CSS project. As I recall this experience, what stands out is how professional and straightforward the interaction was.The owner reached out and asked simple, direct questions about my experience. Nothing complicated. Just clarity.

One of the first messages he sent was:

“Hi DeVontae! We have a short-term project that needs an expert front-end React developer (lots of CSS required). Are you open to a short-term project that may lead to more long-term work?”

We eventually continued the conversation and he told me he was about to meet with his lead developer and would follow up after their meeting. That was another positive signal. He wasn’t making decisions in isolation. There was an actual team involved. About thirty minutes later he messaged me again and asked if I was available for a Zoom call. The call included both him and his lead developer.

This interaction revealed a few things immediately:

• They had an existing technical team

• They valued their developer’s opinion

• They wanted to evaluate candidates collaboratively

After the call, I eventually started work with the possibility of more contract work or employment depending on how things went and whether they landed additional contracts.

He explained his goal clearly:

“My goal as the owner is to not have to do any development by the end of quarter three. If you can fill the development role that I’ve been filling, that would be fantastic.”

He was honest about the situation, honest about expectations, and honest about what success looked like. Looking back, the interaction checked many boxes that I now recognize as signs of a healthy client relationship.

2. They Were Willing to Show Their Face

Another healthy pattern of good clients was being “physically transparent”. If someone refuses to get on camera during meetings or discovery calls, that’s a red flag in my opinion. Some deals may include thousands to hundreds of thousands of dollars. And not being able to “see” who you’re doing business with goes against most cultural norms. Perhaps A.I. will change this. But I truly believe one of the differences between most scam artist and legit clients is physical visibility. When someone is “physically” transparent with the whole process, its a green flag on the journey to finding your ideal client. My best clients were comfortable hopping on Zoom, showing their face, and speaking openly about their business. Below are a couple reasons why being physical visible is important in the client vetting process.

It builds trust

I don’t remember every detail of the convo with Ghost Creative but I remember how I felt. I felt comfortable. Why? Maybe because the owner was a fellow Christian who shared the same faith as me? I believe that could of played a role. But I think I felt comfortable because there was a process. They explained what would happen next. I would meet with the lead developer. I went through onboarding. There was structure. There was a system. And I wasn’t just talking to a name on the internet. I was talking to real people. Seeing their faces mattered more than I realized at the time. It felt real. There’s something psychologically grounding about seeing someone speak about their business. You can hear conviction in their voice. You can see whether they’re prepared. You can observe whether they take the interaction seriously. Contrast that with another experience I had.

Someone once reached out to me about a job opportunity. We scheduled a call. The camera never came on. Everything felt off. Maybe it wasn’t a scam. But the unwillingness to show their face created doubt and didn’t pursue the role.

It confirms identity.

Freelancing today isn’t what it was ten years ago. AI avatars exist. Stolen branding exists. Fake domains exist. Seeing someone live forces alignment between:

• Their LinkedIn presence

• Their company website

• Their online content

It doesn’t eliminate risk. But it reduces anonymity. And reduced anonymity increases accountability. It shows seriousness. You are entering a business relationship. Transparency should go both ways. And that transparency sets the tone for everything that follows.

3. They Were Flexible With Payments (Without Asking for Sensitive Info)

My best clients were flexible. At the time of this writing I’m working with a client on an app that collects data for Superintendents. She was willing to send a check, use Venmo, Cash app and Zelle. We had issues with Zelle so we agreed upon Venmo. This is the type of flexibility you want. In this new A.I. era it doesn’t make sense to give strangers access to personal accounts. I personally wouldn’t give personal access to checking accounts unless I was doing work as a contractor for a legit company or going through a recruiting agency were giving that info is standard procedure. If someone makes sensitive payment info required early in talks and/or complicated or invasive, that’s not friction, it’s a warning that you might be working a with a difficult client at best and a scammer at worst.

Serious clients don’t ask for:

• Your bank login right away

• Personal identification documents unrelated to contract work right away

• Weird payment structures

• “Trial work” without payment

4. They Were Friendly

This one seems small. It isn’t. If someone is rigid, dismissive, or aggressive before you even start working, that behavior will most likely multiply once money is involved.

Good clients:

• Respect your time

• Ask thoughtful questions

• Listen

• Collaborate

Freelancing is a partnership, not servitude. You don’t work for them! You work with them as a technical partner. Remember, you’re not an employee. You’re a business owner. So own your work, own your decisions, and own your mental health by avoiding clients who are difficult to get along with.

5. They Were Willing to Teach and Were Patient

Some of my best clients didn’t just hire me. They taught me. Before I worked at North Built as a full time React developer, I worked with them as a freelancer. And during that time, I went through a PR review with their senior engineers and learned one of my first lessons as a junior: Don’t push console logs into production. I learned many things along the way from them and other clients. A client who is willing to invest time into helping you understand their world is probably invested in your long term success and not just quick results.

6. They Were U.S.-Based (For My Situation)

For me personally, U.S.based clients simplified:

• Time zones

• Contracts

• Payment systems

I also preferred to have U.S. based clients to avoid the friction that sometimes comes from different cultures. For example language! If the clients second language is English, it could be extremely difficult to get in alignment with their needs and problems if I don’t understand them and they don’t understand me. This was a decision I made and one you will need to make for yourself.

Where I Found My Best Clients

Now that you know what to look for in a client, you’re probably wondering:

“How do I actually vet these types of clients?”

LinkedIn

One of the best ways to vet a client is to go to a source (or multiple sources) where they have to be visible to be taken serious. LinkedIn has been my go to source since I started freelancing and doing contract work in 2021. I use LinkedIn as my primary sourcing platform for one main reason: Visibility!

On LinkedIn, serious business owners have to invest time, energy and/or money to gain visibility and to build authority. They post updates. They maintain company pages. They interact with others publicly. That visibility matters. Why? Because visibility takes time!

A scammer probably won’t build a fully professional presence and build an audience base with 10k connections when they can create a quick half baked page to quickly scam someone out of their funds. A bad client who lacks patient will probably forsake a digital footprint. But a serious operator? They leave trails. And the next section will discuss these “trails”.

LinkedIn makes it easy to vet someone before you ever hop on a call. Here a few details too look for:

Does the client have an online reputation?

Remember the patterns I mentioned earlier and how I said my best clients were easy to get along with? One way to vet this friendliness is to see how they interact with other people in the comment sections. Are their responses coarse and in your face? Or are they reasonable and gentle even when responding to harsh comments. They don’t have to be a push over but they shouldn’t be a jerk neither.

Do they market their services?

Remember I said showing your face is a green flag because it means the client is transparent. You can vet how transparent a client is on LinkedIn by looking through their post. Do you see a lot videos of them marketing their brand and services. Videos with client testimonials? Or links to Youtube videos where they are visibly recognized. If so, this a strong indicator the client is legit.

What part of the world do they do business in?

Remember how I said, I filter clients to U.S. based only! You can vet this on LinkedIn by looking at a users profile. It will display their vocational activities and business activities according to were they reside or have resided.

The platform itself creates friction. It requires effort to build a brand and be taken serious on LinkedIn. That filters out a lot of noise automatically. And the main benefit that stems from this friction is professional transparency. And in freelancing, transparency equals knowledge about who you are building for .

Note

Could you find clients on other platforms? Yes. Could a scammer with a lot of patience and wit still hustle someone out of their money on LinkedIn? Yes! There will always be inherit risk. But the goal is to reduce said risk as much as possible while placing safe guards up (i.e. not giving access to personal accounts) in the event you encounter a scammer or unreasonable client.

I need your feedback

What questions do you want answered as someone thinking about freelancing/contracting?

What did you like about the article?

What are your goals?

Leave a comment with these answers or connect with on LinkedIn and/or X

Subscribe now

I’ve spent most of my career as an “Agency” developer. In the agency world, developers tend to be multi client facing positions. These roles require soft skills and context switching into new frameworks and languages. In this article I share how I’ve survived these roles by learning and applying the basics of Software Engineering and roadblocks along the way.

D.R.Y. To the Rescue: From React to Angular

In a agency environment, its not uncommon to be in a Vue codebase one day and switch to React the next. This happened to me with a client who needed help with their Angular application. My expertise was in React, and I knew nothing about Angular. Yet, thanks to the fundamentals I'd learned from senior engineers (and help from chatGPT), I was able to navigate the project with confidence.

The feature I needed to build entailed a new payment processing system. After some discovery and tinkering, I recognized the code I was using would need to be in multiple places across the app. As a junior developer, I probably would had copied and pasted the code making the codebase a nightmare to maintain. But I had learned a key fundamental principle: Don't Repeat Yourself (DRY) from senior engineers. This principle guided me to look for a better solution, even in an unfamiliar framework. After some research, I discovered Angular services, which are perfect for sharing business logic and data across an application. By applying the fundamental principle of DRY, I was able to find the right tool for the job in Angular, creating a more maintainable and efficient codebase.

From Node to Laravel: Navigating the Backend

My client's project wasn't just in Angular; the backend was built with Laravel, a PHP framework. My experience was with Node.js and Express.js. So I was again stepping into unfamiliar territory. However, my understanding of back-end fundamentals helped bridge the gap. For example, I noticed the way Laravel handles routes is similar to how Express.js does it. For example, both frameworks use a similar pattern of mapping HTTP methods (like get, post, etc.) to specific controller functions. I was also able to quickly understand how the codebase was structured, with separations between business logic, validation, and services.

When Lack of Fundamentals hurt: My Angular Roadblocks

While my foundational knowledge of Software principles has helped me with various clients, I’ve learned you still need knowledge specific to a tool. For instance, when I working with the angular client, I was dealing with a skills issue with RxJS operators like switchMap. I was able to work through this by the grace of God and a lot of grit but it was a struggle. If I had known Angular basics like reusable templates and the core concepts of RxJS, I could have solved problems much faster. This experience taught me that while foundational software principles are crucial, a working knowledge of a framework's fundamentals is what really unlocks efficient problem-solving. But no worries, I was able to meet my deadline despite the obstacles with the help of tools like ChatGPT and online resources.

Subscribe now

Image by mcmurryjulie

Intro

Over the past few years, I’ve had the chance to work with Firebase, Supabase, and most recently, AWS and each has shaped my growth as a engineer in different ways. As a freelancer and full time employee, Firebase was the status quo for delivering fast, scalable apps for clients who probably didn’t have the biggest budget. I also experimented with Supabase to build React Native projects on the side with the intent of gaining database design skills. And now, I’m diving into AWS, sharpening my cloud fundamentals so I can bring more value to my current and future clients. Each platform has taught me lessons, sparked frustrations, and ultimately helped me form opinions about why and when you should use each tool.

Firebase: For Engineers who don’t like backend

I recommend that most developers, especially those new to backend work, start with Firebase. I say this as someone who’s used it in both freelance and full-time roles to successfully build web and React Native apps. Firebase takes away a lot of the complexity and lets you focus on shipping.

For example, you don’t need to stress over database design principles. In fact, Firebase breaks certain normalization rules like duplicating data. This simplicity makes it approachable for those who don’t want to live and die by traditional database normalization rules.

Authentication is another big win. With Firebase, spinning up auth is as simple as setting up a listener and calling a few functions. No need to roll your own auth. On top of that, Firebase has been expanding with features like SQL support, even though it’s historically been a NoSQL service. Add in the growing opportunities to integrate AI tools, and you’ve got a platform that continues to evolve without overwhelming beginners.

Supabase: The Sweet Spot for Database Folks

Supabase is perfect for engineers who already have a background in database design and want more control without jumping into the deep waters of AWS.

Like Firebase, Supabase gives you auth and database calls right out of the box. But unlike Firebase, it doesn’t hold your hand. You need to understand schemas, relationships, and SQL fundamentals to really make the most of it. If you’ve already spent time designing databases or have experience with backend features like JWT tokens, Supabase should feel natural.

It sits nicely in the middle ground: lightweight enough for solo developers and small teams, but structured enough that you can flex your backend knowledge. For engineers who like the idea of scaling their skills without immediately going full enterprise, Supabase is the sweet spot.

Subscribe now

AWS: The Cloud Giant’s Playground

And then there’s AWS. AWS isn’t for the faint of heart. Unlike Firebase or Supabase, AWS isn’t a platform you can just poke around in until things click. To succeed here, you need at least a foundation in networking fundamentals and AWS basics.

AWS has a dizzying number of services, and the learning curve is steep. Tinkering aimlessly will only leave you frustrated and potentially leave your application unsafe and/or broken. The smarter path is to invest in a solid course or structured training, then apply those fundamentals repeatedly across projects. Once you get comfortable, AWS opens up possibilities outside of BaaS.

With this in mind, context matters. If you’re building for an individual client or a small startup, I would consider Firebase or Supabase. They’ll let you move fast and deliver value without over engineering. But for clients operating at massive scale or those already locked into AWS services, having AWS skills in your toolkit is an advantage.

Closing Thoughts

Each of these platforms:Firebase, Supabase, AWS has its place. Firebase lowers the barrier of entry and makes app development accessible. Supabase bridges the gap by giving developers more backend control while keeping things approachable. AWS is the heavyweight, demanding serious investment but rewarding you with in demand skills that are utilized in fortune 500 companies. So which one have you learned or plan to learn in the future. Leave a comment.

Subscribe now

Image by Innova Labs from Pixabay

Introduction

I’m currently working with a client who relies heavily on WordPress for their website. Over the past few months I’ve been building new UI features, solving bugs related to Kadence, and fixing user experiences with php code. In doing so, I’ve had a front row seat to the decisions made with WordPress and its ecosystem of third party tools. And here’s something I’ve noticed: many of these decisions while convenient in the short term, have long term consequences for performance, maintainability, and user experience.

What I’ve seen firsthand is that WordPress often allows non-technical users to build, but it doesn’t necessarily guide them toward building correctly. This distinction is important because small decisions (like choosing a plugin, adding a block, or embedding an iframe) can snowball into performance bottlenecks, security vulnerabilities, and frustrating user experiences.

Let’s dig into why content creators, without a developer (or developers mindset), shouldn’t be using WordPress as their go to platform.

WordPress Requires a Developer’s Mindset

On the surface, WordPress seems simple. Drag-and-drop page builders, third-party themes like Kadence, and editors like Gutenberg make it possible to create websites without touching a single line of code. But here’s the catch, building a site isn’t the same as building it well.

Take something simple like a button. A software engineer knows that a button should:

• Change the cursor to a pointer on hover.

• Be disabled after the user clicks it to prevent duplicate actions.

• Provide clear feedback (i.e. spinner) that something is happening in the background if a request is being made.

These may sound like minor details, but they’re what separate a seasoned engineer from a junior engineer. And a frustrating user experience from a smooth one. WordPress doesn’t enforce these practices, it leaves them up to the builder. And unless you’re thinking like a developer, these best practices are often overlooked.

For content creators, this means they might be able to build a page, but they may unknowingly be leaving their users with clunky, confusing, or even broken experiences.

Too Many Plugins

Plugins are one of WordPress’s greatest strength and one of its biggest weaknesses. They offer convenience by letting you add functionality with just a few clicks, but that convenience comes with a tradeoffs:

• Every plugin is another piece of code that could slow down your site.

• Some plugins introduce security vulnerabilities that put users at risk.

• Not all plugins are maintained, leaving your site vulnerable.

I recently removed a file manager plugin from a client’s site because it posed a security threat and it wasn’t necessary. In software development, we have a principle called YAGNI: You Aren’t Gonna Need It. Installing tools “just in case” creates more problems than it solves. But if you’re a content creator without technical knowledge, it’s easy to assume “there must be a plugin for that” without considering whether you really need it or whether it could expose your site to risk.

One Click Could Mean Disaster

WordPress makes it dangerously easy to make bad decisions with a single click (or lack thereof). I’ve seen this firsthand while helping a client improve their web performance.

Their homepage was filled with embedded iframes for Vimeo videos. On the surface, it seemed like a simple way to showcase video content. But behind the scenes, this meant that multiple heavy files were being downloaded the moment someone landed on the site which hurt performance.

This wasn’t a malicious decision. It was a decision made without realizing the consequences. A trained developer would have considered alternatives such as lazy loading to balance performance with user experience.

Subscribe now

What Content Creators Should Do Instead

If you’re a content creator and you choose to use WordPress, the best move you can make is to partner with an experienced development team. Platforms like WordPress are powerful, but they require a developer’s touch to truly shine.

Agencies like Boro Dev Agency specialize in bridging the gap between creativity and technical execution by utilizing seasoned developers like myself (I’m currently a lead engineer at Boro Dev Agency) to handle the technical load.

By collaborating with developers who understand the technical side, content creators can lean into their strengths while knowing the user experience and site performance is taken care of. The result is a website that not only looks good but also works seamlessly for every visitor.

Image by StockSnap from Pixabay

The economy is tough right now, but that doesn’t mean opportunities are not available. Especially for those with even a twinkling of an entrepreneurial spirit. As a former freelancer developer and current contractor, I’ve experienced this firsthand. Over the years, I’ve worked with a variety of clients via LinkedIn and I’ve learned a thing or two about project management, proposal writing, and client relations. One thing I’ve realized is that successfully securing clients isn’t just about skill. It’s about having a system for vetting potential prospects. Recently I’ve developed a simple three method system that will help identify the right clients, avoid pitfalls, and set up projects for success.

1. Discovery

The first phase is Discovery. This is where you truly understand what the client needs and identify their biggest pain points. It’s not about negotiating price at this stage; it’s about uncovering their vision and full desires for a project.

For example, during discovery, I you can ask questions to understand not just what the client wants to build, but why they want it. What problems are they trying to solve? What goals are they trying to achieve? This phase allows you to map out the scope of the project and understand the real value you can provide.

Price may come into play during this phase but I wouldn’t disclose any concrete prices until you gain a thorough understanding of the client’s needs. Rushing into numbers too soon can lead to misunderstandings or projects that are misaligned from the start.

2. Research

Once discovery is complete, it’s time for Research. This phase involves taking everything you’ve learned and exploring the best ways to deliver a solution. The goal is to find practical, efficient, and cost-effective approaches.

For instance:

• If a client wants a content platform but doesn’t write code, technologies like WordPress or another no-code solution may be ideal.

• If the client wants a custom app but has a tight budget, using Firebase for backend infrastructure could be a better tradeoff than deploying an AWS architecture, which may require more time and expense.

The research phase is about identifying options that balance your client’s goals with practical constraints like budget, timeline, and your own expertise. This ensures you can present a thoughtful solution rather than a generic one.

Subscribe now

3. Proposal

The final phase is Proposal. After discovery and research, you’re ready to present your solutions and pricing. This is where your previous work pays off.

Key points to remember in this phase:

• Provide options: Avoid rigid pricing that might turn away a potential client. Offer multiple solutions with different tradeoffs so the client can choose what aligns with their priorities.

• Set fair prices: Your pricing should respect your time and skills while remaining reasonable for the client.

• Stay realistic: Don’t take on work that pushes you outside your expertise, especially under tight budgets or deadlines. For example, if you’ve never deployed AWS in production, don’t “practice” with your first client.

• Be strategic: Sometimes it makes sense to take a small pay cut if there’s a clear opportunity for bigger projects down the road. Always weigh immediate compensation against long term growth and relationships.

I hope the Discovery → Research → Proposal framework will make client vetting much simpler for you. If executed correctly, it should afford you the opportunity to align your skills, time, and business goals with your clients while avoiding projects that could be a mismatch. If you found value in this post share with your network and/or give me a shout on LinkedIn and tell me what you thought of the article.

Subscribe now

Getting started with AWS (Amazon Web Services) can feel overwhelming. With so many services and concepts, it’s easy to get lost. However, you don’t need to learn everything at once. By understanding the fundamentals, you’ll build a solid foundation that makes the rest of AWS much easier to navigate.

I know this firsthand. My background is in JavaScript and React development, but recently I started transitioning into cloud development. The shift began when my current role gave me the opportunity to set up a CI/CD pipeline using Docker and AWS EKS (Elastic Kubernetes Service). Although the full pipeline was put on hold, it sparked a fire that I continue to flame.

The tips I’m sharing below come from research and some from experience. My goal is to save you time, help you avoid common pitfalls, and give you practical steps you can use to start building confidently in AWS.

Think of Your AWS Account as a “Container”

I learned this tip from an Adrian Cantrill course. You can think of an AWS account like a container for everything you do in AWS. And two main components of this container are identities and resources. Identities represent users (i.e. developers, admin personnel, hr,…) who have access to your AWS account with certain permissions. Resources in AWS are things like EC2 instances, S3 buckets, or CloudFormation stacks which provide business value to a company. I appreciate this tip because it affords you the ability to think of AWS from a high level. This high level thinking is necessary when conceptualizing how things work or solving system level problems.

Don’t assume because you’re not using an service, you wont be charged

I was under the impression that as long as I turned a service off (i.e. EC2 server) I wouldn’t be charged because AWS is pay as you go. Unfortunately, this isn’t the case. Yes, AWS is pay as you go. But what does “go” mean in AWS? In AWS if a service like EC2 still has “Resources” available like Elastic IP addresses and Amazon Elastic Block Store (Amazon EBS) volumes, then you are still “going” and will continue to rack up charges. Here’s what amazon’s knowledge center says:

”Stopped instances don't incur charges, but Elastic IP addresses or EBS volumes attached to those instances do”

Use plus addressing for multiple accounts

Its important to understand that emails are what make AWS accounts unique. While multiple accounts can share the same credit card info, emails must be different. To overcame this hurdle, you use an email technique known as plus addressing or sub addressing were you add a plus after your email. Heres an example from a google blog:

If your name was hikingfan@gmail.com, you could send mail to hikingfan+friends@gmail.com or hikingfan+mailinglists@gmail.com.

Keep in mind the second account will be bumped up to the paid plan which means you will need to add billing alerts and be cautious about your usage.

Protect your accounts with MFA

When you first start building with AWS, you may be tempted to whip up VPC’s with EC2’s and add S3 buckets to deploy the next billion dollar SAAS product. But what good is your product if someone can easily hack into your account and shut down your whole business. There’s a proverb that goes, “…and he who hurries his footsteps misses the mark. When you rush the process and ignore best practices like setting up an MFA for your IAM users, you miss the mark of securing your app from fraud and nefarious individuals.

Use Multiple Accounts for Safety and Organization

AWS accounts are decoupled. In other words, a mistake in one account shouldn’t affect others. That’s why its a good idea to use multiple accounts for dev, staging, and production. If a hacker gets access to one, you can utilize the others and possible keep your app running in the mean time. This principle avoids having a single point of failure which is a common systems technique.

Subscribe now

Embrace IAM (Identity and Access Management) Early

IAM is AWS’s way of controlling who can do what in your AWS accountant. It helps you avoid accidents by limiting permissions. For example, if a team member only needs access to the billing info of your account, no need to give them access to an EC2 instance. This is known as giving a user least privileges to avoid “accidents” or fraud. Its also best practice to avoid using the root user which has unrestricted access to your account. Instead, use the root user to create an IAM user with admin privileges (less permissions than root) and give this access to trusted senior AWS cloud engineers.

Understand IAM Identities: Users, Groups, and Roles

• Users: Individual people or applications (e.g., a developer or a backup app).

• Groups: Collections of users who share the same policies (e.g., all developers).

• Roles: Temporary access for AWS services or external entities (e.g., EC2 accessing S3).

Take Advantage of the Free Tier but understand the details

AWS offers a free tier with limited monthly usage of services like EC2, S3, and Lambda. This is a great way to experiment without worrying about costs. But its also important to understand the details around the free tier. For instance, your free tier will end after 6 months or if you’ve depleted your $100 credits. So if you’re using AWS with a course like I’m currently doing, make you are diligently studying your course before your credits or 6 months runs out.

Take your time when learning

I have to remind myself of this because I’m ready to build apps that can scale millions of users. At the same time, I know that I want to be a highly skilled engineer in the cloud and not an hobbyist. And this means a mastery of the fundamentals.

Use multiple sources if you’re trying to obtain an certificate

I did a bit of research and a common theme I found from this reddit thread is you shouldn’t rely on a single resource to pass an exam. Most of the strategies included taking an online course and taking a practice exam at tutorial dojo also knowns as TD.

Subscribe now

Hope you enjoyed these tips. If you found value in this content I encourage you do the one or more of the following:

1. Share with your community

2. Leave a comment

3. Subscribe for more

Image by AS Photograpy from Pixabay

If you're going to build forms, you might as well go a step further and connect them to a Google Analytics 4 (GA4) account and learn the fundamentals of GA4 while you’re at it.

I recently had a real world example of this while working with Ninja Forms in WordPress. I set up a form that didn’t just collect data, but actually tied into a Google Tag Manager (GTM) custom tag that hooked into the a GA4 account. The whole process gave me a deeper appreciation for the overlap between development skills and marketing analytics.

Here’s what happened and why you should care.

The Real-World Example: Ninja Forms + GTM + GA4

I had a client using Ninja Forms on their WordPress site, and they wanted to track/verify specific form submissions in GA4. As part of the discovery process, I created a custom tag in GTM instead of relying on an built-in integration:

• Step 1: In GTM, I created a new tag for the specific form submission event.

• Step 2: I connected it to the right GA4 account by entering the measurement ID (double-check this using the wrong one means your data could end up in someone else’s property).

• Step 3: I tested the entire setup with Tag Assistant for debugging. This made it easy to see whether my tags were firing properly and sending the event data to GA4 in real time.

Once it was working, my form submission triggered an event in GA4.

Why Learning GA4 Matters

1. Added business value

The economy for engineers isn’t exactly sunshine and rainbows right now. The last thing we need is to bury ourselves in another shiny new JavaScript framework with little business impact. Learning GA4, specifically events and key events helps you complement your tech skills with business insights. That makes you harder to replace and more valuable to any team.

2. Diversified skills

If all you know are traditional development skills, you’re playing a risky game in today’s and tomorrow’s market. Adding analytics skill and knowledge spreads your skill set out and can open unexpected opportunities.

3. Easy crossover from coding

GA4 and GTM concepts often overlap with software development practices. For example, naming conventions in coding apply here too: naming an event "event_a" is as unhelpful as calling a variable const x. Good naming makes your data instantly understandable, and developers can pick this up quickly.

Subscribe now

Quick Tips for GA4 + GTM Success

These are lessons I learned while working with Ninja Forms and GTM:

1. Use incognito mode for testing – This might alleviate some pain points when trying to view events in GA4.

2. Check for no-code solutions first – Form plugins like Ninja Forms have built-in GTM or GA4 integrations. If not, you can still inject custom JavaScript in your tags.

3. Verify your measurement ID – Using the wrong one can send your data to another GA4 account entirely.

Final Thoughts

Learning GA4 is one of those small but powerful moves that makes you more valuable. And as my Ninja Forms + GTM project showed me, the skills you already have as a developer make this fairly easy to pick up.

So… how are you leveling up your skills in this crazy market?

I've been hearing about Cursor for a while from fellow A.I. enthusiasts like Will Blackburn, and I finally decided to give it a try for a React Native side project. After diving into it, here are my initial thoughts and lessons I learned.

How I got started with cursor

Download and Installation

The process began with a slow download from the Cursor website. Likely a consequence of being at a busy coffee shop during peak hours. Once downloaded, I placed the Cursor installer in my Applications folder and launched it with the familiar macOS shortcut (Command + Space). The installation was straightforward, setting the stage for exploring its features.

Launching Cursor from the Terminal

After watching various tutorials and noticing how they were manually uploading projects inside cursor, I wondered if I could open a project via a terminal command like I usually do with VS code. After launching cursor I found my answer after noticing the option to install the cursor command in my path variable.

If you decide you don’t want to install the cursor command in your path variable during setup, no worries! You can use the Command Palette (Shift + Command + P + type shell) within Cursor to run the shell command installation at a later time.

🚀Dev knowledge

The purpose of adding the cursor executable to your path is so you can save time. With the cursor executable in your path variable, you can simply type ‘cursor’ instead of /usr/local/bin/cursor in your terminal

🚀Dev tip

You can use the which command to verify if the proper path to execute the cursor command has been added to your path variable. Or test it out with a project

Subscribe now

Cursor sees all

One of Cursor’s standout features is its ability to semantically index your entire codebase. This means it can answer questions using the full context of your code and potentially help write better code by referencing existing implementations. Below are my current thoughts on this feature.

• Amazing Potential:
  I suspect most humans can’t keep the entire context of a large codebase in their mind. This means as your code base grows, cursor should be able to see edge cases and avoid them by making adjustments in your code. This is a potentially game changer.

• Potential Pitfalls:
  If your codebase is messy or if modifications aren’t carefully managed, the results could be confusing or even detrimental. Fortunately, Cursor includes checkpoints, so you can revert to previous states if something goes wrong.

Security and File Management Concerns

Handling Sensitive Files
According to their docs:

While a .cursorignore file can prevent files from being indexed, those files may still be included in AI requests, such as if you recently viewed a file and then ask a question in the chat. We are considering adding a .cursorban file to address the use case of wanting to block files from being sent up in any request

For medium to large companies, this is critical since security should be paramount. Since I'm working on a side project with minimal security concerns, I’m comfortable moving forward with Cursor as it stands. However, organizations with more stringent security needs should watch for updates addressing this file exposure issue.

Final Thoughts

Overall, my experience with Cursor has been positive. It’s a promising tool that could revolutionize how we interact with and understand our codebases. While the potential security and file management issues are something to be aware of, the benefits of semantic indexing and easy integration with your development environment make it a compelling choice for developers. I’m excited to see how Cursor evolves and whether it can become a staple in both small projects and enterprise environments.

What do you think?

Have you had similar experiences with Cursor, or do you have any concerns about its features?

Let’s discuss!

Image by kiquebg from Pixabay

The future of software engineering is evolving, and AI is at the center of this change. The role of the software engineer is not what it used to be, and soon, software engineers will evolve into prompt engineers. Why? Because the tools are changing and businesses are desiring (and perhaps demanding in some cases) more efficiency. In this article, I give three reasons why Software Engineers will become prompt engineers.

Good Prompts Are Based on Understanding

Prompt engineering isn’t just about throwing words at an AI tool and hoping it spits out something useful. Good prompts are grounded in a solid understanding of the problem at hand.

It’s all about understanding

Writing an effective prompt requires you to fully understand the problem, the concept, or the technique you’re working with. A well-crafted prompt can be just as effective as building a solution from scratch. For example, when I was tinkering with Supabase’s SQL editor to create a trigger function, I needed to make sure I understood the fundamental components of a trigger function. Had I not had this understanding, my prompt might had rendered a useless solution.

Prompt engineering in interviews

As prompt engineering becomes more mainstream, we may even see it become part of the hiring process. Instead of asking candidates to build entire projects from scratch, companies might test their understanding through effective prompts. Understanding how to guide AI will soon be just as important as understanding how to write code. And that shift might change how software engineers are evaluated in interviews.

Everyday Tools Are Implementing AI Editors

It’s no secret that AI is being integrated into the tools developers use every day. These tools are getting smarter, and they’re making the development process faster and easier, pushing prompt engineering to the forefront.

Tools like Cursor AI and Supabase’s SQL Editor are leading the charge

These tools streamline code completion, debugging, and even database object generation. They’re designed to take the heavy lifting out of the development process and give developers more time to focus on higher-level tasks.

When tools like these are widely used by the development community, it’s a clear sign that things are shifting. What was once a niche skill is now becoming a standard practice in software engineering. As more tools adopt AI features, developers will naturally gravitate toward mastering prompt engineering.

Subscribe now

It Makes Business Sense

Businesses run on efficiency, and nothing drives efficiency like AI. The adoption of prompt engineering isn’t just a trend—it’s a smart business move.

The efficiency drives profits

The goal of any business is to be profitable, and one of the most effective ways to increase profitability is through efficiency. Prompt engineering allows developers to complete tasks in half the time, reducing costs and increasing output. Businesses are going to expect, if not demand, their engineers to integrate prompt engineering into their workflow because it gets results.

Faster results mean more value

When engineers can use AI to cut development time in half, they add tremendous value to the company. More can be accomplished in less time, and the business benefits by getting products to market faster, reducing development costs, and boosting overall profitability. In short, prompt engineering isn't just a skill—it’s a business strategy.

Conclusion

Software engineering is evolving into prompt engineering. Everyday tools like Cursor and ChatGPT are making prompt engineering an essential skill. The future of software engineering isn’t just about writing code anymore—it’s about knowing how to ask AI to do it for you.

Image by Petra from Pixabay

To answer the title of my post, “because there are a multitude of options”. The Expo Framework is one of my favorite frameworks for building universal apps. But that doesn’t mean its without pain points. And one of its pain points is the various ways or “builds” you can use when creating React Native apps. In this article, I aim to bring structure to the chaos of setting up projects with React Native Expo. Lets start with where you can build your app.

iOS simulator/device vs Android emulator/device

Expo is a robust framework for building cross-platform mobile and web applications. When developing with Expo, you have four environments to run/test your application: the iOS simulator, Android emulator, iOS device, and Android device. Each of these options has its own set of pros and cons. For example, if you don’t own an iOS device you can still test your app with an iOS simulator. However, certain features can’t be properly tested when working on a iOS simulator. I ran into this issue while developing an app called GigBoss for a former employer. One of the features in GigBoss allowed users to tap on a phone number and link it to the native phone app. Unfortunately, this feature couldn’t be tested on a simulator because it didn’t have access to the native system. For a step by step process on setting up different environments for your React Native app, click here. After you decide where your app will run, its time to decide how you will build it.

Expo Go

After you decided where you want to develop (i.e. android device) your
Expo app, the question becomes how will you do it . One option is to implement Expo Go. Expo Go is a “sandbox” environment for building React Native apps. If you’re building your app in an iOS simulator or Android Emulator, run the command npx expo start within the Expo CLI. After running this command, Expo Go will be installed automatically on your virtual devices.

Pros of Expo Go

Expo Go is great for getting up and running with a local environment. If you’re curious about React Native and want to start tinkering with no fuss, Expo Go is a good starting part.

Cons of Expo Go

Expo Go is great for enthusiast who want to develop quickly because it hides native directories and the ability to modify files in native directories. But this comes with less flexibility. For example, if you want to use the expo-camera library, you need to use config plugins or configure native files. However, in an Expo Go environment, you don’t have access to these native files. As a result, you won’t be able to install the expo-camera package and will need to find a suitable alternative. One way around this limitation is implement a local build in Expo.

Subscribe now

Expo Local Build

One way to work around the limitations of Expo Go is by creating a local build (also known as a debug build). A local Expo build gives developers greater flexibility and control by providing access to native directories and files. If you want to use the expo-camera library mentioned earlier, you would need to run the following command in the Expo CLI: npx expo run:ios (or npx expo run:android for Android). Once this command is executed, the iOS and Android directories will become available, allowing you to use the expo-camera package.

Pros of Expo local build

Affords you the ability to use more third party packages for more robust app experiences

Cons of Expo local build

With greater control comes greater complexity and more opportunities for bugs and errors

Expo Local Build + expo-dev-client = development build

I mentioned earlier that a local build is also considered a “debug” build. When you combine this build with the expo-dev-client package, Expo considers this a development build. Like a local build, a development build affords you access to native iOS and Android directories. However, there are cases when you will need to use a development build over a local build. A prime example of this is when you’re using a third party auth service like Facebook login. When testing a third party auth system with Expo, its instructed that you use a development build. According to Expo’s docs, you can create development builds remotely, locally, or within your own infrastructure.

Pros of Expo development build

Greater feature flexibility (i.e testing Auth services) beyond a local build

Cons of Expo development build

A bit confusing and added complexity

Expo Snack

If you’re a web developer and you simply want to test the waters of React Native (ie. the fundamentals) I would start here. I believe a lot of devs are naturally curious about React Native because its a great accompaniment to their established React skills. But sometimes its important to “test drive” new tools before you go all in. Expo snack is perfect for this scenario.

Pros of Expo Snack

Great for testing and/or practicing in the browser

Cons of Expo Snack

Not suitable for production apps

Recap

1. Start with Expo Snack if you just want to go on a test drive

2. Venture off with Expo Go if you want to set up something locally and tinker without a lot of fuss

3. Create a local build when you want greater flexibility with your features

4. Create a development build for scenarios where its required like using a third party auth service

Share

Image by Christopher White from Pixabay

The world of software development is on fire at the time of this writing. Between React Server Components, Firebase adopting SQL and Open A.I. creating faster and cost affordable A.I. tools, it's clear that staying relevant in this field requires continuous learning and adaptation. But how do you navigate the latest trends? Do you forsake whatever path you’re on and go all in on the latest tech? Or do you ignore the current landscape and hope your current skills will suffice for the foreseeable future? The aim of this article is to give you practical tactics to navigate the latest trends and any trends that might come down the pipeline in the future.

Tips for Navigating the Change

While it’s exciting to see such rapid advancements, it’s essential to approach these changes thoughtfully. Here are some tips to help you stay balanced and strategic in your learning journey:

Don’t Be Too Hasty

Not every company will abandon their current tech stack in favor of the latest and greatest technologies overnight. Legacy code is still prevalent, and many businesses will continue to rely on it for years to come before they’re forced to change. The slow adoption of some companies means more time for you to gradually build new skills. Think of learning new technologies as an investment—one that will pay off in the future. When you have a long term mindset, being hasty becomes less tempting.

Don't Be Too Relaxed

While some companies will adopt new tech at a snail-like pace, it is very probable that other companies will be early adopters of new tech. Because of this, I encourage you to start learning new skills as soon as you can. And because years of experience has a high currency in the world of tech, the sooner the better.

Subscribe now

Master the Basics First

Though it’s tempting to jump on the AI bandwagon or dive into the latest React features, I wouldn’t encourage this practice unless you’ve studied the basics. Without a solid foundation in coding principles and problem-solving skills, you’ll be building Software on shaky ground. With this in mind, before you decide to go all in on the latest trends, I would verify that you’ve done the following:

1. Developed mastery with a programming language

2. Understand coding principles like S.O.L.I.D and DRY

3. Have strong fundamentals ahead of any updates to frameworks, API’s, and services you want to use (i.e. understanding React state before utilizing Server Components)

Find a Niche path

Given the plethora of new technologies and tools, it can be overwhelming to decide where to focus your efforts. Today, you might come across information about server actions in react or how Firebase is adopting adding SQL. Instead of trying to learn everything at once, focus on the tech that aligns with your interests and career goals. For example, if you’re goal is to be a front end specialist, being concerned with how Firebase is evolving may not make the most sense. But if you’re a Full Stack developer that uses React and Firebase, learning both would be a reasonable decision.

Conclusion

The world of software development is exciting and full of opportunities. By balancing your approach to learning you can navigate this ever-changing landscape effectively. Embrace the change, invest in your skills, and prepare yourself for the future of development.

Image by StartupStockPhotos from Pixabay

Have you ever been told that you should post more on LinkedIn? Perhaps you were told this advice in order to build a brand and/or secure a full time job. Perhaps you were told this so you could grow your audience to secure more clients. Regardless of why you were told this advice, there remains a problem:

Telling someone what to do, isn’t the same as guiding them on HOW TO DO IT.

In this article, I aim to address this gap by sharing practical strategies for posting more consistently on LinkedIn. And it all starts with two things:

1. Setting aside a time to create your content (i.e. Saturday mornings at 10am)

2. Organizing your content into categories that inspire and spark ideas.

The majority of this article will focus on categories you can use to spark ideas that will help you post more consistently on LinkedIn.

Categories

The content categories I will present, which you may have encountered online but never considered structuring into a system, have been instrumental in building my audience. These categories are a blend of concepts I've learned from Justin Welsh and Matt Gray. One way to apply these categories is by setting them in a spreadsheet and writing down various post titles that come to mind. For example, in the tips and tricks category (I discuss this category next) you could write the following:

1. How to convert any value in javascript to a boolean

2. How to use the null coalescing operator in javascript

Regardless of how you use these categories, the goal is for them to organize your creative thinking instead of trying to curate ideas from scratch. The remaining of the article will focus on the different categories that can help you create consistently on platforms like LinkedIn.

Tips and Tricks

As a Software Engineer who regularly engages on social media platforms like LinkedIn, you’ve probably come across a post showing you how to do some nifty thing in Javascript or a popular framework like React. Tips and tricks are a great way to build authority and demonstrate your technical ability. Next time you're looking for inspiration for your LinkedIn posts, consider highlighting those small yet invaluable skills that could benefit your audience.

If you don’t know any tips and tricks, I encourage you to learn some and share with your audience. By doing this, you’ll continue to grow your craft and build your brand

Lessons

If you’re struggling to find ideas for your LinkedIn post as a Software Engineer, think about the lessons you’ve learned along the way that can help someone else in their tech journey. Did you spend way too much on a bootcamp when you could of took a more affordable online course? Did you get a degree when you could of went to a bootcamp? Whatever the lesson, be willing to be vulnerable and share with your audience for their benefit. Here’s a personal lesson:

As I look back on my journey, one big lesson sticks out to me: I should of started small by building simple landing pages. Had I done this, I would had been prepared for entry level jobs that only required basic html and css skills.

When my audience hears this, they will value their small wins and not be overwhelmed with all there is to know in the tech industry.

Playbooks

When I think of playbooks, I think of what actions and strategies did someone use to drive their desired results. As a Software Engineer, you can talk about study habits, sleep routines, or any habit that drove any victories you’ve achieved. You can also observe and discuss someone else’s playbook in your post and how you plan on using their tactics

Subscribe now

List

The idea behind list or listicles, a term I learned from Justin Welsh, is to give your audience a list of things that could be beneficial for them. For example, you could list 7 courses you took that helped you level up as a Software Engineer. Or a list of “go to” Node packages you use in every project. You could even list new javascript features like temporal that may be introduced in the Javascript ecosystem.

Personal stories

By personal stories, I don’t mean Situationships or seasons in your life that include “juicy details”. I mean personal stories that reflect your journey as a Software Engineer. Personal stories are a great way to connect with your audience, future clients, and/or employers. In a world were A.I is ever increasing, I believe personal stories, based in truth, will gain tremendous value. An example of a personal story, as a Software Engineer, could be the hardship of trying to find your first job and how you managed to stay positive and resilient through the process. Or it could be how you weren’t resilient and how you plan to be going forward. I’m persuaded the more vulnerable we are as humans, the more we connect with each other.

Tradeoffs

As a Software Engineer, recognizing tradeoffs is crucial to writing good code. Recognizing tradeoffs is also a good way to spark ideas for post to provide value to your audience. An example of a tradeoff post could be the tradeoffs between Next.js and Remix. Or the tradeoffs between using Zustand and Redux.

Observations

The Observation post should focus on trends or patterns you’ve observed in the tech industry. For example, I’ve noticed from being in the industry as a full time and contractor, that React Native and Firebase is a go to stack among engineering teams. Making your audience aware of this can provide value in streamlining what technologies they should focus on.

Contrarian

The Contrarian post is focused on challenging established ideas and providing a new perspective. For example, using the Context API as a global state manager is a an accepted practice. But based on research, I would challenge this idea and say it shouldn’t be used for global state. Instead, it should be used to avoid prop drilling per Reacts docs.

The contrarian post isn’t for the faint of heart. Be ready for push back with this one.

Past vs Present

The past vs present post can take on various forms but the heart behind it is this: Communicating with your audience how something (i.e tech market, frameworks, languages,…) used to be one way and how its changed. For example, maybe you believed Redux wasn’t the way to go at some point in time. But since RTK has streamlined the process, you now think Redux is a viable competitor in the world of state management. Maybe you use to think React Query was necessary. But with Server Components popping up, you’re thinking differently. Whatever the case, the Past vs Present post is a good way to provide your audience with a Birds Eye view on the ever changing landscape in tech.

Word of encouragement

These categories will most likely serve you best when you do the following:

1. Schedule a time to write

2. Start small (i.e 5 LinkedIn post a week)

3. Be authentic

Tell me about your results

If you decide to use these categories to curate LinkedIn post, tell me how it goes.

✌🏾

Image by StartupStockPhotos from Pixabay

Deciding to invest time and resources into a coding bootcamp is a monumental choice for anyone aspiring to break into the tech industry. It’s not uncommon for a junior dev to ask, “Should I join a bootcamp or go university?” At the end of the day, I can’t answer this question directly for anyone. But what I can do is share what I would look for based on past experiences in the tech industry. And based on this insight, I hope it will help you make an informed decision on whether a bootcamp is worth your time, energy and money. In light of this, I would only join a bootcamp if…

They set reasonable expectations

There are a lot of bootcamp marketing that suggest you can get a full time job with 6 months experience. Based on my own observations and personal experience, this is highly unlikely. It took me a year and some change before I landed a full time job in tech. And this time frame seems to be the norm as of this writing. If a bootcamp is “selling you the dream”, I would consider this a red flag. If they’re setting reasonable expectations and willing to share journey’s similar to mine, they might be worth your time.

Its taught by at least one Senior Engineer

The opportunity to learn from senior engineers is invaluable. Their guidance through code reviews and insights into modern coding practices, such as the D.R.Y. principle and clean code, is fundamental. The mentorship from those who've navigated the tech landscape is vital to your professional development. I speak with confidence about these things because I’ve personally been trained by senior engineers and have seen how their mentorship and guidance can excel the learning process. With this in mind, I highly encourage you to consider a bootcamp where you will receive extensive training from senior engineers or engineers with more experience than you (i.e a mid level engineer).

It Includes comprehensive coverage on software design principles

In an industry often dazzled by the latest and greatest frameworks and languages, the timeless principles of software design can get lost in the noise. If a bootcamp emphasizes foundational concepts like D.R.Y. and Orthogonality, they will equip you with the skill set to build resilient and scalable code regardless of the tech stack you’re engaged in. I learned these principles from a previous employer and it completely changed my approach to code.

They teach modern frameworks

The tech industry is ever-evolving, and so are its tools. A bootcamp should not only introduce you to Software design principles but also ensure you’re comfortable using contemporary frameworks. These are the tools you’ll likely encounter in today’s tech environment and familiarity with them can significantly ease your transition into the workforce. With this in consideration, I encourage you to consider bootcamps that stay up to date with the latest technologies. If you’re considering a bootcamp as of this writing, I would check and see if they teach one or more of the following: React, Next.js, React Native,Tailwind, and/or Express.js.

Subscribe now

Code reviews are given by Senior Engineers

Earlier I mentioned that I wouldn’t a join a bootcamp unless it was taught by senior engineers. But as the saying goes, there’s more to the story. Reflecting on my journey, the constructive feedback from code reviews conducted by seasoned engineers was a cornerstone of my growth. As highlighted by the wisdom in Proverbs 16:20, "Those who listen to instruction will prosper." Engaging in this iterative process of review and improvement is crucial for honing your coding skills.

Cloud training is part of the curriculum

As the industry leans more towards backend and deployment skills, understanding cloud services is becoming vital. A bootcamp that includes cloud training acknowledges the shifting landscape of tech and will prepare you for the challenges and opportunities that occur in deploying and managing applications at scale.

Database management skills are taught

Data is often described as the new oil. If this is true, becoming skilled in creating and querying databases will be to your advantage. A forward thinking bootcamp will cover the fundamentals of database management and design, as they teach you the critical role data plays in technology.

Word of caution

The following list isn’t meant to say, “If a bootcamp doesn’t meet ALL these requirements, avoid them”. Instead, it should be a guideline for you to determine what value you will gain from a bootcamp and is it worth the cost of admission. I believe there are a lot of bootcamps whose main intent is to capitalize on the gold rush known as “breaking into tech”, instead of honestly communicating to career changers about the realities of the industry and the necessary skills that are required. This article is an attempt to engage in the honest conversation.

Image by lumenbrite from Pixabay

prerequisites: Basic understanding of React and Typescript

Currently, typescript is all the rage and is certainly becoming a mandatory skill javascript developers should know. In this article, you will learn about type inference, constrained generics, iterating over keys from a type and more. I will also demonstrate how these tools work in the context of a React/React Native project that is using Firebase as a backend. The examples I use will be based on a few observations and issues I came across while working on a personal project.

The issue at hand

While working on a React Native app for my portfolio, I stumbled across a typing issue while implementing a feature that allows a user to update their account information. In order to implement this feature, I used the updateDoc method given to us from Firebase. The beauty of this method is it allows developers to update some parts of a document without overriding the whole document. The example below will demonstrate what our function will look like without types. It’s part of an api service layer.

The code below will display the state being passed to the updatedInfo argument.

When I decided to type my updateUser function, I utilized standard typing practices:

1. I made id a string type

2. I made the return type a Promise<void>

3. And I wanted to make sure any values passed to updatedInfo matched my User type

The obstacle appeared when I decided to type updatedInfo with my User type. When I tried to do this, I received the following error:

Argument of type 'User' is not assignable to parameter of type '{ [x: string]: any; }

I could of used the type unknown, but upon further investigation, I learned I could create a type on the fly by iterating over the keys from my User type.

The keyof User syntax will return a union of key values from my User type for typescript to iterate over. After iterating over the User keys, the updatedInfo argument will have a type equal to the original User type as shown below.

Now typescript is happy and we’re completely type safe.

Subscribe now

Type inference

lets say we didn’t implement a User type explicitly on our local react state. Instead, we decided to go with type inference by only setting an initial value as seen below.

There’s a drawback to this approach. If I add a value to my state object (i.e.password), typescript wouldn’t throw an error with the current implementation. To remedy this situation, you can use generic constraints on the updateUser function. By adding a generic constraint (example below), we make it “mandatory” for the object being passed to the updatedInfo argument to possess the same keys as my User type.

By adding extends after the generic T, I’m telling typescript that the value of T must be constrained to a certain type. In this example, our generic is constrained to a union of key values given to us via keyof User. Now if I try to add something to my React state that doesn’t match my User model (as demonstrated below), I will receive a typescript error.

A quick note on type inference vs explicit types

As developers, one of the biggest obstacles we will face throughout our career is Company A will use certain standards and practices that Company B wont. This is why I decided to demonstrate two different scenarios and solutions concerning our typing issue. The goal of this article isn’t to make a claim that one is better than the other but to show the nuance approaches to typescript and React. I hope you learned something new. And if you found value from this post, share, comment, or subscribe to my newsletter.

Image by Mohamed Hassan from Pixabay

In the first installment of our series on RTK Query and Firebase, we laid the foundation by establishing an API layer and learning about its advantages. In part two, you will learn how to leverage the API layer with RTK Query and gain benefits such as avoiding unnecessary calls to our Firebase database when the data hasn’t changed.

What is RTK query

Similar to React Query, RTK query is a data fetching and caching tool. When you request data with Firestore functions, RTK query is responsible for executing the request, providing the results from the request, and the current state of your request (i.e, isLoading, isError, isSuccess). These request are given via the API layer created in part one of this series. The rest of the series will focus on implementing our Firebase API layer with RTK query so you will gain the benefits of caching and invalidation.

How to implement RTK query

Lets start by examining the variable name menuItemsApiSlice from the code example above. The slice suffix is a naming convention you'll often encounter when working with RTK and RTK query. This convention is employed because it signifies a distinct portion (or slice) of your overall state store. In our current example, it represents the part of our store that deals with menuItems. Setting up a store is beyond the scope of this tutorial. Instead, I'll illustrate how to integrate RTK query using the API Provider near the end of the lesson.

Another crucial aspect to highlight is the createApi function. As its name suggests, this function plays a pivotal role in crafting our API. It takes an object as its argument were each property assumes responsibility for managing your request to a backend server. The details of each property will be explored in the upcoming sections.

baseQuery

The baseQuery property is responsible for setting the root url of all your API request. Because we will be using Firebase, the fakeBaseQuery method is called. This is an alternative that RTK query gives us when we don’t have a traditional url like this: https://pokeapi.co/api/v2/

If we were using a traditional url like the one above, our baseQuery property would accept a fetchBaseQuery method, which accepts an object with the property baseUrl, instead of the fakeBaseQuery.

fetchBaseQuery Example

endpoints

There’s plenty to cover in this code example. Lets take it one step at a time by starting with the endpoints property.

endpoints

This createApi function is responsible for creating your queries that will make calls to a backend server. How does it do this? By using a function (assigned to the endpoints property) that receives a builder object as an argument and returns an object that uses the properties from the builder object (i.e, builder.query) to make queries. All of this is demonstrated in the code above where fetchMenuItems is using the builder.query method to make an api call to our Firestore database. At this point, we have officially connected our api layer created in pt1 of this series, to RTK query. Lets now dive deeper in understanding the builder.query method

builder.query

Currently our fetchMenuItems query is assigned the builder.query method. This method accepts an object as its value and is responsible for making read request to our database. The builder.query method expects two types. The first is a return type, while the second is a type parameter. The former represents the value the function assigned to queryFn should return. The latter represents the value this same function should receive as an argument. If you go back to part one of this series, you will see we’re returning the exact shape our queryFn function expects.

Its also worth mentioning that the builder object also contains a mutation property (i.e, builder.mutation) for making mutations (updates or deletes) to the Firestore database. You will learn later how mutation queries can invalidate data that was previously fetched.

queryFn

In the last section, you learned the return type and type parameter(s) our builder.query expects. Both are managed by the function given to the queryFn property. Because we passed void as the second type to our builder.query method, we don’t pass anything to our queryFn function. However, since we explicitly typed our return type to be an object with the properties payload and lastDocument, we must make sure our data property returns this exact object.

The reason I’m returning an object with the data property is because I’m using queryFn instead of query. If I were using the fetchBaseQuery, mentioned earlier in the tutorial, I would had used the query property and wouldn’t need to return a data object.And if you didn’t return the appropriate object, you might receive the following error message below.

queryFn did not return anything. It needs to return an object with either the shape `{ data: <value> }` or `{ error: <value> }`

Subscribe now

tagTypes, providesTags, invalidatesTags

So far you have the knowledge and skills and to read data from a Firestore database with RTK query via an API layer. But what happens if you decided to make a mutation to data that was previously read from the database? How does RTK query handle this scenario? The answer is “tags”.

In the code example above, you will notice our code introduces the tagTypes and providesTags properties. The tagTypes property allows you the ability to invalidate data. And the provideTags properties allows you to provide tags to a specific query so it will respond to invalidation. Lets break this down with the following example:

Lets say you mutate your Firestore database and this effects data that was previously read from your database. Because you created a tag (MenuItems) via tagTypes and provided that tag via providesTags to fetchMenuItems, fetchMenuItems would refetch the new data. How can you make sure this process happens? By adding an invalidatesTags with the same value as the providesTags property to a mutation query. Below is an example of a query mutation that would trigger fetchMenuItems to get called again.

How to use queries with custom hooks

Since our queries are established, we can implement them in our code base via hooks. RTK will automatically generate this hooks from the createApi method if you import them from @reduxjs/toolkit/query/react. Below is an example of the custom hook RTK query will automatically create behind the scenes for us.

Here’s an example of the hook being used in a React component. Notice it provides the status and results of our network request with the following values: data, isError, isLoading. Refetch is used to force a refetch. I’ve used this feature in a React Native project when the users internet is disconnected and they need to refresh the screen.

How to use RTK query with an API provider

We have our API Layer integrated with RTK query and we have custom hooks that allow us to make API request in our React components. However, none of the functionality we’ve implemented will be useful until we incorporate an API Provider (or a store if you choose) with our menuItemsApiSlice as an api value in our App.tsx file.

This concludes today lesson. I hope you learned something new. If you have questions regarding this article, feel free to reach out to me on LinkedIn.

Image by Pexels from Pixabay

Prerequisite: Basic familiarity with Firebase concepts like collections, documents, and queries

In this two part series, you will learn how to implement RTK query in a React Native project backed by Firebase. Part one will teach you how to build an API layer when building mobile/web apps and why you need one. In part two of this series, you will learn how to implement an API layer with RTK query. Both parts will focus on retrieving data from firestore, rather than altering it.

If you want to follow along in your own sandbox, import the @reduxjs/toolkit package. You’ll also need a Firebase backend connected. If you’re not familiar with setting up a Firebase project with React Native, you can check out a previous article I wrote here. Or watch this video starting around the 5 minute mark.

Why you should create an API layer

A very common practice in React is to use an useEffect hook to make API calls in a React component as demonstrated below.

While this approach can work well with smaller applications, it will start to become a headache if you try to scale it across multiple components. What if you’re lead engineer decides to use Axios instead of fetch? You would need to update many components to accommodate such a decision. Such an event, would expose your design decision as being complex.

In his e-book, ”A philosophy of Software design”, John Ousterhout states change amplification as a symptom of complexity.

When you couple API calls to React components, you increase complexity within your code base as it grows because a simple change will require modifications in many different places. So how can you make your code less complex?

In his book, “React, The Road To Enterprise”, Thomas Findlay encourages developers to separate their API code from the rest of their code for the following benefits:

Adaptability

I will demonstrate how to create an API layer with Firebase. But what if you’re in a situation where the team lead decides to transition from Firebase to Supabase? Or what if your team hires a .NET developer and decides to build a custom made API? If you’ve created an API layer, it will be easier to adapt to these changes.

standardisation

When you create a separate API layer, you can avoid the temptation to use fetch in one part of your app and Axios in another. In other words, an API layer creates a path that future developers or you future self wont have to guess about.

Subscribe now

Firebase API layer

Lets break this code down. The first thing to notice is the file path. By creating an API directory and placing all of our code that hits “endpoints” on our backend, we create a layer between React Native and our backend.

Another point to notice is the menuItemsApi file holds code related to all menuItem features. Right now it only holds code to getMenuItems but in the future if I wanted a feature that allowed a user to add menu items, I would put it in the menuItemsApi file.

Finally, if I decided to go with Database functions from Supabase, I would replace my code in this directory instead of trying to update multiple parts of my app.

If you’re familiar with Firebase V9, you can skip the following section. If not, continue reading to understand the rest of the code in menuItemsApi.

Firebase V9 methods

query - The query method, as the name suggest, is meant to query our database according to parameters a developer will set. Right now its querying my menu items collection according to the genre field. It will also limit my request to 3 documents per request.

menuItemsRef - This variable represents the collection or data I want to query. Behind the scenes it looks like this:

const menuItemsRef = collection(db, "Menu Items");

The code above is telling firebase to allow us access to the Menu Items collection in our database

orderBy - The orderBy method is responsible for how our returned documents will be sorted. By placing “genre” as an argument to the orderBy method, I’m telling Firebase to send me menu items in alphabetical order according to their genre. For example, my current database has menu items with the following genre: Burgers, BBQ, and Asian Food. With my current query and orderBy method, Firebase would return my documents in this order: Asian Food, BBQ, Burgers

limit - This method is responsible for limiting the amount of documents a query will return. My current example will return 3 documents at a time.

getDocs - Opposite of getDoc which returns a single document, getDocs returns multiple documents and is appropriate when making queries without knowing the results in advance.

lastDocument - This variable is holding the last item’s genre from the results of getDocs. This is the beginning of the process for creating pagination with cursors. Pagination is beyond the scope of this article.

payload - This variable will receive the results from our getDocs request and with lastDocument will be given to RTK query to manage our request and server state. This will be demonstrated in part two of this series.

Updated useEffect example

If we revisit our previous useEffect example, we will see our code is more Orthogonal or decoupled.

Now if we decided to use Axios, Supabase, or something other database technology, we would only need to change the code in our API directory and not throughout the whole app. In part two, you will learn how to implement our API ayer in RTK query where you will gain the benefits of caching and network state management.

Subscribe now

Ways to support my newsletter

🖥 If you believe this content is valuable, share it on social media

🎤 If you believe I would be a good fit for a podcast, let your favorite podcaster know

Connect with me

Connect with me on LinkedIn!

Connect with me on Twitter!

Related Articles:

Image by Memed_Nurrohmad from Pixabay

In part 1 of React vs React Native, I discussed basic React Native components such as View, Button, and Pressable. You also learned and how to style these components with the Style Sheet object. In today’s article, you will learn other foundational components needed in most React Native projects. If you desire to follow along with the code examples, click here!

SafeAreaView

The SafeAreView is like a special “div”. It prevents your Components from interfering with the status bar area. This is the area where the time and wifi icon are located. 

 return (
    <SafeAreaView style={styles.container}>
     //...
    </SafeAreaView>
  );

caveats

Though the SafeAreaView is a popular and easy solution for preventing interference with the Status bar area, it isn’t supported on all devices.

According to the React Navigation docs

While React Native exports a SafeAreaView component, this component only supports iOS 10+ with no support for older iOS versions or Android. In addition, it also has some issues, i.e. if a screen containing safe area is animating, it causes jumpy behavior.

SafeAreaView alternative

If you need consistent layout design across many devices and without any animation hiccups, consider using the useSafeAreaInsets hook given by the react-native-safe-area-context library Full implementation of this hook is beyond the scope of this article but you can play around with the code here!

TextInput

The TextInput component is similar to the input element found in a traditional React app but with a few caveats. For instance, instead of using onChange to handle state, it uses onChangeText which accepts a string instead of an object.

 return (
    <SafeAreaView>
      <TextInput
        style={styles.input}
        onChangeText={onChangeNumber}
        value={number}
        placeholder="placeholder"
        keyboardType="numeric"
      />
    </SafeAreaView>
  );

caveats

In a conventional React application, attributes such as input, name, id, and type are considered standard. However, React Native inputs diverge from this system. The following list are props worth knowing when using React Native’s TextInput.

keyboardType

This prop receives values like, numeric, email-address, and phone-pad.

onSubmitEditing

This prop’s function is called when the user hits submit on their device. When combined with a ref, it can focus the next input after a user has submitted a value.

blurOnSubmit

This prop is used to keep the keyboard from flickering when transitioning from one input to the next.

Subscribe now

Navigation

The following code uses React Navigation to navigate between screens. The Navigation container is a mandatory wrapper to implement navigation in a React Native project. You can think of the Navigation container as a BrowserRouter . Inside the Navigation container is another React component known as a Stack Navigator. The Stack Navigator is a mandatory wrapper for Stack Navigation, or navigation between to different screens.The options prop allows developers to configure the header bar of a React Native project.

React Native sandbox

import { View,Text,Pressable,StyleSheet } from 'react-native';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';

function HomeScreen({navigation}) {
  return (
    <View style={styles.view}>
    <Pressable 
      style={styles.btn} 
      onPress={()=>navigation.navigate("Screen1")}
    >
      <Text>Go to Screen1</Text>
    </Pressable>
    </View>
  );
}
function Screen1({navigation}) {
  return (
    <View style={styles.view}>
     <Pressable 
       style={styles.btn} 
       onPress={()=>navigation.navigate("Screen2")}
      >
        <Text>Go to Screen2</Text>
      </Pressable>
    </View>
  );
}
function Screen2({navigation}) {
  return (
    <View style={styles.view}>
      <Pressable  
        style={styles.btn}  
        onPress={()=>navigation.navigate("Home")}
       >
        <Text>Go To Home Screen</Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  btn:{
    borderWidth:1,
    height:40,
    borderColor:'#f4511e',
    padding:10,
    width:"80%",
    alignItems:"center"
  },
  view:{
    flex: 1, 
    alignItems: 'center', 
    justifyContent: 'center' 
  }
})

const Stack = createNativeStackNavigator();

function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator
        screenOptions={{ 
            headerStyle: {
              backgroundColor: '#f4511e',
            },
            headerTintColor: '#fff', 
          }}
      >
        <Stack.Screen
          name="Home"
          component={HomeScreen}
          options={{
            title:"Home"
          }}
        />
        <Stack.Screen
          name="Screen1"
          component={Screen1}
          options={{
            title:"Screen1"
          }}
        />
        <Stack.Screen
          name="Screen2"
          component={Screen2}
           options={{
             title:"Screen2"
           }}
        />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

export default App;

This concludes today’s lesson. If you have questions, don’t be afraid to message me on twitter or LinkedIn.

Ways to support my newsletter

🖥 If you believe this content is valuable, share it on social media

🎤 If you believe I would be a good fit for a podcast, let your favorite podcaster know or invite me on

Connect with me

Connect with me on LinkedIn!

Connect with me on Twitter!

Image by RealToughCandy.com

A common question I get from experienced React developers interested in React Native is, what are some of the differences between React and React Native. I will explain some core differences in today’s article. This will not be an exhaustive list but it will be a great starting point for those interested in learning about React Native. You can follow along with the React Native examples by copying and pasting code in a tool called Expo snack found here!

View vs div

A div element is a common component in a traditional React project. It’s main purpose is to control “where” its children will reside. The same is true for React Native’s View component. It’s main responsibility is acting as a “layout” component that will control where and when (if there’s conditional rendering) a component will be seen. The following code will place a Text component (we’ll discuss in the next section) in the center of the screen.

import { Text, View, StyleSheet } from 'react-native';
import Constants from 'expo-constants';



export default function App() {
  return (
    <View style={styles.container}>
      <Text style={styles.paragraph}>
        Center of page
      </Text>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    paddingTop: Constants.statusBarHeight,
    backgroundColor: '#ecf0f1',
    padding: 8,
  },
  paragraph: {
    margin: 24,
    fontSize: 18,
    fontWeight: 'bold',
    textAlign: 'center',
  },
});

Caveats

Though the div and View component share similarities, there are some key differences worth noticing:

Syntax

The first thing to consider is syntax. React Native components start with capital letters. This isn’t a big deal but you may have to retrain your brain when context switching between a React and React Native project.

onclick vs onPress

If you ever needed to make a div component clickable for some reason, you would simply add an onclick handler to take care of your needs. To make components clickable in a React Native project, you would pass a function to the onPress prop. However, this prop isn’t available on a View component.

If you need a clickable container component in a React Native project, you can use the Pressable component as seen in the code below.

import {useState} from "react";
import { Text, View, StyleSheet,Pressable } from 'react-native';
import Constants from 'expo-constants';



export default function App() {
  const[textColor,setTextColor] = useState("red")
  
  const handlePress = ()=>{
    setTextColor("blue")
  }
  
  return (
    <View style={styles.container}>
      <Pressable onPress={handlePress} style={styles.btn} >
        <Text style={[styles.paragraph,{color:textColor}]}>
         Click
        </Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  btn:{
    border:"blue",
    borderWidth:1,
  
  },
  container: {
    flex: 1,
    justifyContent: 'center',
    paddingTop: Constants.statusBarHeight,
    backgroundColor: '#ecf0f1',
    padding: 8,
   
},
  paragraph: {
    margin: 24,
    fontSize: 18,
    fontWeight: 'bold',
    textAlign: 'center',
  },
});

In the code above, I created a custom button via the Pressable component. When the user clicks on the button, it will change the color of the text. You can copy and paste the code here to test it out.

Text vs h1,h2,h3…..

In React Native, the Text component is responsible for all things copy in your mobile app. To simulate the same feel you would get in a traditional React app, you can combine a design theme in your project and utilize that to create various text sizes. You can learn more here! But for now, remember the Text component is responsible for ALL of your text needs. The code below will demonstrate how you can adjust a Text Component’s fontSize.

import {useState} from "react";
import { Text, View, StyleSheet,Pressable } from 'react-native';
import Constants from 'expo-constants';



export default function App() {
  const[textColor,setTextColor] = useState("red")
  
  const handlePress = ()=>{
    setTextColor("blue")
  }
  
  return (
    <View style={styles.container}>
      <Pressable onPress={handlePress} style={styles.btn} >
        <Text style={[styles.text,{color:textColor}]}>
         Click
        </Text>
      </Pressable>
      
      <Pressable style={styles.btn} >
        <Text style={[styles.text,styles.h1]}>
         Click
        </Text>
      </Pressable>
    
      <Pressable style={styles.btn} >
        <Text style={[styles.text,styles.h2]}>
         Click
        </Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  btn:{
    border:"blue",
    borderWidth:1,
    marginTop:10
  },
  container: {
    flex: 1,
    justifyContent: 'center',
    paddingTop: Constants.statusBarHeight,
    backgroundColor: '#ecf0f1',
    padding: 8,
   
},
  text: {
    margin: 24,
    fontWeight: 'bold',
    textAlign: 'center',
  },
 
  h1:{
    fontSize:40
  },
  h2:{
    fontSize:30
  },
});

Subscribe now

Button vs button

React Native’s Button component is very similar to a standard button in a React project but with a few twist. First, instead of calling an onclick handler, you call onPress. Also, when you use the Button component in React Native, your telling each OS to use their standard button style. In other words, your design wont be consistent across the iOS platform and Android platform.

To remedy this situation, you can create a custom button via the Pressable component which I discussed earlier. This will maintain a consistent layout and experience for the user. The code below will demonstrate the differences between creating a custom button with a Pressable component and using the Button component. If you copy and paste the code in the expo snack environment and change platforms, you will notice the Pressable components stay the same across Android and iOS, while the button component looks different on each platform.

import {useState} from "react";
import { Text, View, StyleSheet,Pressable,Button } from 'react-native';
import Constants from 'expo-constants';



export default function App() {
  const[textColor,setTextColor] = useState("red")
  
  const handlePress = ()=>{
    setTextColor("blue")
  }
  
  return (
    <View style={styles.container}>
      <Pressable onPress={handlePress} style={styles.btn} >
        <Text style={[styles.text,{color:textColor}]}>
         Click
        </Text>
      </Pressable>
      
      <Pressable style={styles.btn} >
        <Text style={[styles.text,styles.h1]}>
         Click
        </Text>
      </Pressable>
    
      <Pressable style={styles.btn} >
        <Text style={[styles.text,styles.h2]}>
         Click
        </Text>
      </Pressable>

      <Button title="button" onPress={()=>console.log("btn clicked!!!")}/>
    </View>
  );
}

const styles = StyleSheet.create({
  btn:{
    border:"blue",
    borderWidth:1,
    marginTop:10
  
  },
  container: {
    flex: 1,
    justifyContent: 'center',
    paddingTop: Constants.statusBarHeight,
    backgroundColor: '#ecf0f1',
    padding: 8,
   
},
  text: {
    margin: 24,
    fontWeight: 'bold',
    textAlign: 'center',
  },
  
 h1:{
    fontSize:40
  },
  h2:{
    fontSize:30
  },
});

StyleSheet object vs the world of css

Bootstrap, Tailwind, and CSS modules are all ways to do CSS in traditional React apps. However, in React Native the StyleSheet object allows you to apply styling to your components with Javascript when you call its create method. It’s essentially a CSS abstraction that allows you to use common terminology like fontSize and backgroundColor.

To implement a style from the StyleSheet object, you must use the style prop on your component. The variable named styles can be called whatever you want but the React Native convention is to call it “styles”

The Text component style property is accepting an array of styles to combine multiple style objects
 
<Pressable onPress={handlePress} style={styles.btn}>
    <Text style={[styles.text,styles.h1]}>
         Click
     </Text>
 </Pressable>

const styles = StyleSheet.create({
 //...
  text: {
    margin: 24,
    fontWeight: 'bold',
    textAlign: 'center',
  },
 
  h1:{
    fontSize:40
  },
  h2:{
    fontSize:30
  },
});

Subscribe now

Alternatively, you can use a third party package like styled components if you’re not a fan of the StyleSheet object .

applying multiple styles

You may have noticed that some of components have an array of styles in their style prop.

  <Text style={[styles.text,styles.h1]}>
      Text goes here
  </Text>

 const styles = StyleSheet.create({
   //...
  text: {
    margin: 24,
    fontWeight: 'bold',
    textAlign: 'center',
  },
 
  h1:{
    fontSize:40
  },
  h2:{
    fontSize:30
  },
});

When you want a component to “inherit” multiple styles from a StyleSheet Object, you can use an array to combine your styles. One thing to keep in mind is the last property in an array of styles will override all other properties. In other words, if the first property in the array has a fontSize of 10 and the last one has a fontSize of 20, that components fontSize will be set to 20

The fontSize on this Text component will be 40 since styles.h1 takes precedence over styles.text

  <Text style={[styles.text,styles.h1]}>
     Text goes here
  </Text>

 const styles = StyleSheet.create({
   //...
  text: {
    fontsize:10
    margin: 24,
    fontWeight: 'bold',
    textAlign: 'center',
  },
  
  h1:{
    fontSize:40
  },
  h2:{
    fontSize:30
  },
});

This concludes today’s lesson. If you learned something, consider subscribing and sharing this article with the rest of the dev community.

Subscribe now

Ways to support my newsletter

🖥 If you believe this content is valuable, share it on social media

🎤 If you believe I would be a good fit for a podcast, let your favorite podcaster know

Connect with me

Connect with me on LinkedIn!

Connect with me on Twitter!

Related Article

Image by krzysztof-m from Pixabay

One way to dynamically change css properties with styled components is to insert a custom prop into your React component and access said property using the dollar sign and curly braces commonly used for template literals. 

Our current example is testing to see if our use pointer prop is true. If it is, the cursor property will be set to pointer. If it is not, it will be set to grab.

Here's the component with the prop titled usePointer

Subscribe now

Our first example allowed us to change one css property in one go. What if we wanted to change multiple css properties. How would we accomplish such a task? The answer lies in a helper given to us by the styled components library called ‘css’. 

Our current example is validating two props: props.changeColor and props.changeBorder. Both are given to our original Button component and controlled by state using React hooks. If we click said button we will see our Buttons css dynamically change.

Here's component using the props changeColor and and changeBorder

Ways to support my newsletter

🖥 If you believe this content is valuable, share it on social media

🎤 If you believe I would be a good fit for a podcast, let your favorite podcaster know

Connect with me

Connect with me on LinkedIn!

Connect with me on Twitter!

Image by Pexels from Pixabay

Within this article, you will discover two approaches to seamlessly integrate Firebase into your expo project. If you are not yet familiar with expo, I encourage you to click here for further insights. While both paths offer their merits, it's important to note that they come with their own drawbacks. However, before delving into these paths, let's first explore the compelling reasons why learning Firebase is a valuable pursuit.

Why learn Firebase

It’s ubiquitous

Whether I was working on freelance projects, contract work, or a full time position, I found myself interacting with a Firebase backend. Because of its great adoption amongst businesses, I believe its a safe bet for anyone wanting to dip their toe in the world of backend technologies.

A.I. focused

I believe that the era of A.I. has firmly taken root and is here to stay. Companies and individuals who embrace A.I.-centric technologies will undoubtedly have an advantage over those who don’t. Firebase serves as a prime illustration of forward-thinking companies that have integrated a Machine Learning service into their array of backend technologies. If you aspire to enhance your skill set with A.I.-focused technology, delving into Firebase could prove to be a rewarding endeavor.

A plethora of learning material

When it comes to acquiring new knowledge, the availability of learning resources plays a pivotal role. In my personal experience, Firebase stands out for its wealth of resources catering to diverse learning preferences. Its documentation provides first-class examples and engaging videos for visual learners, while a plethora of YouTube videos and articles cater to your desire for further exploration.

Subscribe now

How to connect Firebase to your Expo projects

Firebase JS SDK

If you want to get started with firebase services like cloud Firestore, you can use the Firebase JS SDK in your expo project. This SDK is perfect if you wish to use the expo go app for your React Native project.

Firebase JS SDK caveats

If you're new to the React Native ecosystem, it's important to understand that there are two prevalent approaches for building React Native apps: Expo CLI and React Native CLI. Within the Expo CLI, there are various methods to interact with your React Native app, with one of them being the Expo Go app. Expo Go provides a quick and convenient way to kickstart your development journey while sparing you the complexities associated with custom native code typically encountered in the Expo Bare Workflow or React Native CLI Workflow. However, it's worth noting that opting for Expo Go means foregoing access to essential Firebase features such as Analytics, Dynamic Links, and Crashlytics. These powerful tools require the management of native code, which is not accessible within the Expo Go app.

React Native Firebase

If Firebase tools like Analytics, Dynamic Links, and Crashlytics is a must, than you will need to use the React Native Firebase package in replace of the Firebase JS SDK.

React Native Firebase caveats

If you decide React Native Firebase is best for your needs, than you will carry the burden of managing native android and iOS code. If you’re using the managed expo workflow and you want to use React Native Firebase, you’ll need to create a development build or use the expo run command expo run:[ios|android] for either iOS or Android. If you want detailed instructions on how to use the React Native Firebase package, use the expo docs and the React Native Firebase docs.

Ways to support my newsletter

🖥 If you believe this content is valuable, share it on social media

🎤 If you believe I would be a good fit for a podcast, let your favorite podcaster know

Connect with me

Connect with me on LinkedIn!

Connect with me on Twitter!