DEV Community: JealousGx

Why Clients Don’t Hire the Most Skilled Freelancer

JealousGx — Thu, 26 Mar 2026 05:02:19 +0000

Introduction

A common assumption in freelancing is:

“If I improve my skills, I’ll get more clients.”

It sounds logical. But in practice, it’s often incomplete.

Many highly skilled freelancers still struggle to get replies, while others with average technical ability consistently land projects.

The difference is rarely skill alone.

It’s clarity.

The Reality of Client Behavior

Clients don’t analyze profiles deeply.

They don’t carefully compare every freelancer.

They scan.

In a few seconds, they try to answer:

What does this person do?
Can they solve my problem?
Do I trust them enough to message them?

If your profile doesn’t answer these questions quickly, the client moves on.

No matter how skilled you are.

Why Skill Alone Isn’t Enough

Most freelance profiles focus heavily on:

technologies (React, Node, Python)
long descriptions
generic claims

But this creates a problem.

From a client’s perspective, many profiles start to look identical.

And when everything looks the same, nothing stands out.

The Role of Clarity

Clarity is what turns a profile into a conversion tool.

A clear profile:

communicates a specific service
highlights outcomes instead of tools
removes unnecessary complexity
makes it easy for the client to understand value

Clarity reduces friction.

And lower friction leads to more replies.

What Clear Positioning Looks Like

Instead of:

“Full-stack developer with experience in multiple technologies”

A clearer version would be:

“I help SaaS startups build scalable web applications using modern full-stack architecture.”

The second version answers:

who you help
what you do
what kind of outcome to expect

That’s what clients are looking for.

Small Changes, Big Impact

One of the most overlooked aspects of freelancing is how small improvements can significantly change results.

For example:

rewriting your headline
improving the first 2–3 lines of your profile
structuring your proposals better

These changes don’t require new skills.

But they can improve how clients perceive you.

What I Noticed While Building a Tool

While working on GigScale, I reviewed many freelancer profiles.

A clear pattern emerged:

Most freelancers were capable.

But their profiles didn’t communicate their value effectively.

Once clarity improved, their positioning improved — and so did their chances of getting replies.

Conclusion

Freelancing is not just about being skilled.

It’s about being understood.

You don’t need to be the best freelancer in the world.

You need to be the clearest one in front of the client.

Because in most cases, the freelancer who gets hired is not the most skilled.

It’s the one who makes the decision easiest.

Why Most SaaS Apps Fail After Launch

JealousGx — Mon, 23 Feb 2026 14:58:22 +0000

Most SaaS products don't fail because the idea is bad.
They fail because they were never engineered to scale.
In the early days, everything looks fine. The app works. Users sign up. Feedback is positive.
Then growth happens.

And the cracks start to show.

Built for Demo, Not for Production

Many early-stage products are built to validate an idea quickly. That's good.
But the problem starts when demo-level code becomes production code.
Common issues:

Hardcoded logic
Poor folder structure
No proper error handling
No logging or monitoring
No clear separation of concerns

What worked for 20 users becomes unstable at 200.
A production-ready system requires intentional architecture - not just functional code.

No Scalability Planning

Scalability is rarely an afterthought. It's either designed in from the beginning or painfully retrofitted later.
Typical mistakes:

Blocking operations in APIs
No caching strategy
No rate limiting
No background job processing
No thought about concurrent users

A system that works locally doesn't automatically work under load.
Full-stack scalability means:

Optimized frontend rendering
Efficient API structure
Proper database indexing
Thoughtful cloud deployment

Poor Database Design

Your database is the foundation of your SaaS.
If your schema is messy, everything on top of it becomes fragile.
Common problems:

Missing indexes
Unoptimized queries
Over-fetching data
Incorrect relationships
No normalization strategy

When the database struggles, users feel it instantly:
Slow dashboards.
Delayed responses.
Random timeouts.
And users don't wait.

Ignoring Infrastructure

Many products focus only on frontend and backend logic, ignoring infrastructure entirely.
Questions most teams don't ask early enough:

How will we monitor errors?
What happens if the server crashes?
How do we handle traffic spikes?
Do we have automated deployments?
Is there a rollback strategy?

Infrastructure isn't optional. It's part of the product.
Deployment, monitoring, CI/CD, logging, these are not "later problems."
They are core system components.

No Clear Ownership of the Entire System

This is where full-stack thinking matters.
A real full-stack approach isn't just:
"I can write React and Node."
It's:
"I understand how frontend performance, API structure, database design, and cloud infrastructure all connect."
When someone owns the system end-to-end, the product becomes coherent.
When responsibility is fragmented, cracks appear quickly.

Building SaaS the Right Way

A scalable SaaS product requires:

Clean architecture
Structured backend APIs
Thoughtful database design
Optimized frontend performance
Production-ready infrastructure

It doesn't need to be over-engineered.
But it must be intentionally engineered.

Final Thoughts

Ideas are important.
Execution is critical.
Architecture is what determines whether your SaaS survives growth, or collapses under it.
If you're building something meant to last, build it like a product, not like a demo.

The Backend Finally Makes Sense, Why I'm Loving Motia

JealousGx — Thu, 28 Aug 2025 09:59:43 +0000

If you’ve ever pieced together a backend with Express routes, cron jobs, background workers, and a few AI agents duct taped together, you’ll know it works… but it’s not exactly pretty.

You end up with code scattered across files and folders, logs in three different places, and brittle workflows that are hard to debug or extend.

Recently, I came across Motia, and it kind of blew my mind.

It’s an open source backend framework that actually feels modern, and dare I say, fun to use.

What is Motia?

Motia is a code first framework that helps you build APIs, background jobs, scheduled tasks, and AI agents, all in a single project, with a shared runtime and clean visual feedback.

It’s built with developers in mind and aims to make backend development feel as intuitive as frontend frameworks like NextJS.

What Makes Motia So Good?

🧱 Everything is a “Step”

In Motia, the basic unit is a Step. It can be:

An HTTP API endpoint
A cron job
A background task
An AI agent
An event handler

Each step is just a function, but Motia stitches them together into workflows that you can visualize, monitor, and interact with in real time.

🧑‍💻 Polyglot Support (Yes, for Real)

One of the coolest things about Motia: you’re not locked into one language. You can write steps in TypeScript, and Python (more coming soon), all in the same project.

That means you can:

Use Python for AI or data stuff
Stick with JS/TS for APIs
Experiment with Ruby if that’s your thing

Perfect for teams or anyone who’s not monolingual.

⚡️ The Workbench = Your Dev Superpower

Motia comes with a builtin dev UI called the Workbench. It’s your local dashboard where you can:

Trigger steps manually
Inspect inputs, outputs, and logs
See how everything connects
View live executions and errors

It’s like DevTools, but for your backend.

🧠 Built-In State and Logs

You don’t need to spin up a Redis instance or wire up logging just to track state or debug a flow.

Motia gives you:

Simple key-value state with TTL support
Execution tracing
Builtin observability
A real-time view of what’s happening

All out of the box. No config overload.

What Can You Build with Motia?

Honestly? A lot.

REST APIs and microservices
Background workers
Internal tools
AI bots and agents
Data pipelines
Scheduled jobs (goodbye, messy crons)
Prototypes that actually scale

And the best part? All of it lives in the same repo, with a consistent model.

Getting Started Is Super Simple

Just run:

npx motia@latest create -i
cd your-project
npx motia dev

Then head to http://localhost:3000 to start building in the Workbench.

From there, you can create your first step (like a simple API or a scheduled task) and actually see it run live, without waiting for a deploy.

Final Thoughts

I’ve built a lot of backend projects over the years. Most of them were glued together with frameworks and tools that weren’t really meant to work together.

Motia changes that. It’s one of the first tools I’ve seen that really treats the backend as one cohesive system, not a bunch of disconnected services.

If you’re into clean architecture, rapid iteration, and building with joy, I think you’ll love it too.

Check it out here
Star the repo on GitHub

Let me know what you build, I’m genuinely curious.

How to Market Your First SaaS(When You Know Zero About Marketing)

JealousGx — Sat, 02 Aug 2025 04:00:57 +0000

After publishing my last article on how to launch your first SaaS as a software engineer, I got good number of questions: “But how do you market a product when you know nothing about it, and with all the restrictions on different platforms?” Instead of replying to each comment, here’s my honest take based on my journey with FounderSignal.

“I Have a Landing Page… Now What?”

You’ve built a clear landing page. Congrats! But just sharing that page on Reddit, X, Indie Hackers, or Slack won’t suddenly bring waves of users, many platforms have strict rules about promotion, and people are wary of cold pitches.

What Actually Works: Give, Then (Much Later) Ask

I learned the hard way: dumping your product link everywhere just gets ignored (or worse, flagged as spam). The only thing that brings results is providing value before you promote.

Concrete Example: Reddit Done Right

Suppose someone posts:

“What’s the best way to validate a SaaS idea if I’m not sure people will pay or even use?”

Wrong way:
“Check out my site, FounderSignal, it helps you do that!” (Likely removed by mods, gets zero engagement)

Right way (short, valuable, subtle):
“I’d start by talking to real potential users first, ask what they’d pay for, not just what’s ‘nice to have.’ For what it’s worth, I built something to help with this but learned a ton just by DMing people and asking direct questions.”

Notice:

The comment helps others whether or not they click anything.
Your product gets mentioned naturally.
You’re not demanding attention, you’re being useful in the conversation.

**Tips for New Users on Reddit (and Everywhere Else)

Observe First: Lurk in relevant subs for a week or more. Note what gets upvoted and what gets removed or downvoted.
Comment Before Sharing: Make at least 10+ genuinely helpful comments with no mention of your product.
DMs for Details: If people ask for more info, then send your link or explain how your product works.
Self-Promotion Rule: Read and honor each sub’s self-promotion policy, many care far more about how you participate than what you say.
Ask Honest Questions: Sometimes “How would you solve X?” gets more engagement than “Here’s my product.”

Pro tip:
This “give before you take” approach earns trust everywhere: Indie Hackers, Product Hunt, and even LinkedIn. When I first posted about FounderSignal on indiehackers, producthunt, and similar platforms, zero feedback! Only after I spent real time helping others did people start replying, engaging, and eventually asking about my product.

Why Building in Public is Crazy Necessary

If you’re building your first SaaS, don’t just build in silence, build in public. This means sharing your journey, wins, roadblocks, and even your unfinished work openly on platforms like X, LinkedIn, Reddit, or Indie Hackers. Don’t worry about “What if others steal my idea”. You’re gonna be left behind with this mindset.

Here’s what building in public does for you:

Builds Trust: People see you as a genuine creator, not just a seller.
Attracts Early Users and Collaborators: Followers who watch your progress tend to become your first customers and biggest advocates.
Gets Faster Feedback: Your audience can offer suggestions, point out bugs, or share encouragement.
Makes You Memorable: Transparency makes your startup stand out from quiet launches.

In my experience launching FounderSignal, being open about my process made it easier to gain valuable feedback and support, way more than cold promotion ever did.

Another Powerful Approach: Write for Large Publications

Beyond social channels and forums, another high-impact way to market your SaaS is by writing for large publications that already have a substantial reader base.

Publishing a blog post in a well known outlet allows you to:

Reach tens of thousands of readers instantly
Establish credibility by appearing alongside other respected voices
Naturally share your product and link while providing genuine value through tips, stories, or how-tos

For example, in this very article, I’m showing you helpful strategies and including my FounderSignal, demonstrating how you can give actionable advice, share your journey, and spotlight your SaaS without being spammy. If your story solves a real problem, it’s welcome!

Quick tips for large publication posts:

Always lead with value: Share a unique lesson or actionable tip before mentioning your product.
Seamlessly weave in your product as “what worked for me” rather than the focal point.
Follow the publication’s guidelines and engage with commenters after publication to build relationships.

The Biggest Lesson

Since launching FounderSignal, this mindset shift has made all the difference:
Your primary “marketing” as an engineer isn’t plugging a product. It’s showing up, helping (without strings), and being patient.
Only after people trust you as a real contributor do they care what you’ve built.

You don’t need to be a marketing genius, you just need to be a helpful, genuine part of your target community. That’s what gets you noticed, and that’s what leads to real feedback and early users.

How to Launch Your First SaaS as a Software Engineer (With Zero Marketing Experience)

JealousGx — Mon, 28 Jul 2025 05:23:58 +0000

When I built and launched my first SaaS, FounderSignal, I had zero background in marketing, or any of the “business” stuff you see in startup blogs. My biggest lesson? You don’t need to be a marketing pro to build a great product and grow a real community. Here’s my step-by-step playbook, crafted for other engineers just starting their SaaS journey.

1. Start With a Clear, Honest Landing Page

Don’t just code , start by making your idea visible.
A simple, appealing landing page is your MVP’s first test. Focus on:

Explaining what pain point you’re solving, in plain language.
Outlining exactly how your solution is different or better.
Sharing a relatable story or problem. You don’t have to build this from scratch: Use no-code tools (like FounderSignal, Carrd, Typedream, or Framer) to launch a fast, professional page. Many platforms now let you track user engagement, heatmaps, and even analyze traffic patterns with builtin AI. This helps you learn early, before writing a single line of app code, if there’s genuine interest.

2. Share It Where Your Audience Hangs Out

Don’t wait for users to find you. Proactively:

Post your landing page on X, LinkedIn, Reddit, and any niche communities related to your problem space.
Tell the story: What problem inspired this? How has it impacted you or others?
Ask for thoughts, feedback, and signal of interest. Track who’s clicking, what they say, and how people interact. Real-time reactions (even if it’s just “this is cool” or “I don’t get it”) are pure gold for steering your next steps.

3. Validate Signals, Then Build Your MVP

Only move forward if you’re seeing “good signals”, enough signups, DMs, or demo requests showing people want this.

Then, build your MVP. Keep it lean, focus just on the core solution, even if it’s buggy or incomplete. While building, adopt a “build in public” mindset:

Share screenshots or progress on X, Reddit, LinkedIn, or YouTube.
Talk about small wins, roadblocks, and why you’re making certain choices.
Invite others to follow your journey or even test things early. Shipping fast matters way more than perfection.

4. Launch and Close the Feedback Loop

As soon as your MVP is live:

Share it back with every group or person who showed interest.
Broadcast the launch on all channels, don’t be shy!
Most importantly, ask for feedback the moment people try it out. Iterate fast. Fix what matters most. Ship improvements. Repeat.

Main Point: Build With Your Community

It took me building and launching FounderSignal to truly get this: listen, launch, learn, repeat.
You don’t need to be a marketer, just stay open, share often, and let your earliest users help you shape the product. That feedback loop builds both a better SaaS and a real community around it.

How to Stop Wasting Months on Startup Ideas Nobody Wants

JealousGx — Wed, 23 Jul 2025 05:27:10 +0000

Are you tired of pouring your heart and soul into a startup idea, only to launch and hear nothing but silence?

You’re not alone. Most founders dream big, work hard, and invest months coding, tweaking, and hoping for success. But investing effort is no guarantee you’re building something people want.

The Smarter, Faster Way to Validate Startup Ideas

What if you could 'test drive' your idea, without any code, and know for sure if real people care before spending months or money? Imagine getting results in just days.

That’s the problem we designed FounderSignal to solve.

Why Validation Trumps Guesswork

Save Time and Money: Instantly see if your idea gets genuine interest.
Build with Certainty: Know you’re creating something customers actually want, not just hoping.
Make Data-Driven Decisions: Use real engagement signals and AI-powered insights, not just your gut.

How FounderSignal Helps

Set up a fake MVP landing page in minutes.
Track real user engagement, see who visits, signs up, and how they interact.
Get AI insights.
Learn early, pivot fast, and avoid costly mistakes.

Ready to Validate Your Idea?

Don’t wait until launch day to find out if people care. Get real validation, not guesswork.

Try FounderSignal today, and make sure your next idea has real demand before you build.

Why Most Startups Fail, And How I’m Trying to Help Founders Beat the Odds

JealousGx — Sun, 20 Jul 2025 08:29:40 +0000

So, I’ve launched my first SaaS (FounderSignal) and honestly it feels a bit wild, like standing on a brand new basketball court with nobody around to play.
Everyone talks about validating your startup idea, but no one tells you how lonely it can be when you really start.

I spent weeks (okay, months) building stuff nobody actually wanted before. This time? I flipped the script. Instead of hoping for the best, I tried to get feedback before writing a single line of code.

A few things that surprised me:

Most founders (including me) are afraid to ask strangers if the idea stinks.
When I finally did, the feedback wasn’t as harsh as I imagined, most people actually wanted to help.
Early feedback saved me from chasing “nice to have” features.

FounderSignal is my way to help other builders who don’t want to gamble months for a “maybe.” The thing I wish I had last year: quick, real feedback from real humans.

If you’re building anything (SaaS, side project, new app), skip the guesswork. Share your idea early, test it before you build, and talk to people who’d actually use it.

I’d love to swap stories or hear your own “startup fails” (the real, embarrassing ones). Let’s help each other out so fewer ideas die quietly in someone’s downloads folder.

Any tips for getting your first real user? Drop ‘em below. I’m still learning, and I bet you’ve got tricks I haven’t tried.

The Hidden Pitfall of Next.js Fetch Revalidation: A Real-World Debugging Story

JealousGx — Wed, 16 Jul 2025 04:44:34 +0000

When building FounderSignal, a platform for startup idea validation, I ran into a subtle but critical issue with Next.js’s fetch revalidation that every developer should know about. This post will walk you through the problem, the debugging journey, and the solution, with practical code snippets and lessons learned.

The Problem: Stale Data, Strange Headers

I wanted to cache API responses for a long time, ideally, a year, using Next.js’s fetch revalidation. My fetch looked like this:

const response = await fetch("https://api.jsonplaceholder.com/v1/users", {
  next: { revalidate: 31536000 }, // 1 year in seconds
});

It worked locally and on the first deploy.
But after refreshing the page on Vercel, I started seeing this:

content-type: text/xml
content-length: 0
No actual data, even though my API was returning the correct JSON.

The Debugging Journey

At first, I suspected my API. I checked logs, tested endpoints, and confirmed the API was returning the right data and headers.

But the deployed Next.js app was serving an empty response with the wrong content type. Why?

The Culprit: Extremely Long or Infinite Revalidation

After hours of debugging, I discovered the issue:
Setting revalidate: 31536000 (1 year) or Infinity caused Vercel’s Next.js server to serve a broken cached response after the initial fetch.

Even though Next.js docs mention Infinity is supported, in practice, it led to:

Stale or empty cache entries
Wrong content-type headers
No data on subsequent requests

The Fix: Use a Reasonable Revalidation Interval

Switching to a 1-day revalidation fixed everything:

const response = await fetch("https://api.jsonplaceholder.com/v1/users", {
  next: { revalidate: 86400 }, // 1 day in seconds
});

Now, every page refresh returns the correct data, and the cache works as expected.

Key Takeaways for Next.js Developers

1. Don’t Use Extremely Long or Infinite Revalidation

Even if the docs say Infinity is supported, it may not work as expected on all platforms (especially Vercel). Stick to practical intervals like 1 day (86400 seconds) or less.

2. Always Check Response Headers

If you see content-type: text/xml or content-length: 0 from a Next.js route that should return JSON, suspect a caching or revalidation issue.

3. Debug Both API and Frontend

Don’t assume the bug is in your API. Sometimes, the frontend framework’s caching layer is the culprit.

4. Use Tag-Based Revalidation for Manual Control

If you want to serve stale data until a specific event (like a new user creation), use tag-based revalidation:

// Fetch with tag
const response = await fetch("https://api.jsonplaceholder.com/v1/users", {
  next: { tags: ["users"] },
});

// In your action or API route
import { revalidateTag } from "next/cache";
await revalidateTag("users");

Conclusion

Caching and revalidation are powerful features in Next.js, but they can introduce subtle bugs if not configured carefully. If you’re building a project like FounderSignal or any data-driven app, test your caching strategy in production-like environments and avoid extremely long revalidation intervals.

Have you faced similar issues? Share your story or questions below!

Happy coding, and may your caches always be fresh!

Build A Responsive Sidebar with React and Styled Components

JealousGx — Wed, 24 Aug 2022 11:23:20 +0000

Why does Sidebar / Navbar exist?

Navigation is the most easiest way to go through the website. The navigation links can be displayed either in Sidebar or Navbar. Both services are widely used by most of the websites.

What will we be building?

In this article, we will be building a simple yet responsive sidebar, step-by-step using ReactJS, styled-components, and React Router DOM as our major dependencies. This sidebar will be fully responsive on all devices, a demo of which is present here.

Pro: We will also be learning one of the folder structures in this react app.

Prerequisites

Before diving into coding this component, you need to make sure you have good knowledge of:

HTML, CSS, JavaScript
ReactJS
Styled-components
React Router DOM

Moreover, you also need have:

NodeJS (Stable version)
NPM and / or Yarn

Building the component

In Command Prompt, navigate to the directory where you would like to create the project and type:

1. Install the React App

# With npm
npx create-react-app react-sidebar

# With yarn
yarn create react-app react-sidebar

where react-sidebar is the project directory name. Now open this project directory in your favorite code editor. I will be using Visual Studio Code.

Now, keep index.js, App.js and App.css and delete the other files / folders inside src folder. This will clean up most of the react app.

Inside public folder, keep index.html file and delete all other files / folders.

2. Add the packages to the react app

Install Material UI Icons, React Router DOM, styled-components. Run the following command to get them installed on our react app:

# With npm
npm install @mui/icons-material @mui/material @emotion/styled @emotion/react react-router-dom styled-components

# With yarn
yarn add @mui/material @emotion/react @emotion/styled react-router-dom styled-components

Let's connect the whole app with react-router-dom so that its functions / components can be used everywhere. Replace the code in src/index.js with the following:

// src/index.js
import React from "react";
import { BrowserRouter } from "react-router-dom";
import ReactDOM from "react-dom/client";
import App from "./App";

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <React.StrictMode>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </React.StrictMode>
);

First and foremost, we need to use react-router-dom to create links to different pages within our app. So, we need to connect the whole app with its parent component which is BrowserRouter. This will give us access to use almost all of the components, the said package has to offer.

To do so, at first, we import the parent component and wrap the App component inside the parent component. This App component covers our whole app and we can use React Router anywhere within our app.

Run the app in your browser using npm start or yarn start and head to localhost:3000 to view the changes.

Now, let's create the routes / pages using react-router-dom. Replace the code in src/App.js with the following code:

// src/App.js
import { Routes, Route } from "react-router-dom";
import { DynamicItem, Sidebar, dummyData } from "./components";
import "./App.css";

function App() {
  return (
    <div id="main">
      <Sidebar>
        <Routes>
          <Route path="/" element={<DynamicItem page="homepage" />} />
          {dummyData &&
            dummyData.map((item, index) => (
              <Route
                key={index}
                path={item.path}
                element={<DynamicItem page={item.name} />}
              />
            ))}
        </Routes>
      </Sidebar>
    </div>
  );
}

export default App;

Here, we are importing Routes, Route from react-router-dom which will help us create pages within our app. We are also importing the Sidebar component, which we will be creating after sometime, dummyData, some random data which includes path to our pages, DynamicItem, a dummy page which displays the page name as we navigate to it.

Next thing, we need to do is use the Sidebar component. This component will be such that it will accept children as props so that it is visible everywhere as we navigate between the pages. Right after that, we need to add Routes component, a container which covers our pages / routes as we create them so that the app knows this is a routes container and it contains pages.

Now, the only thing we need to do is add the routes we want. We know that dummyData contains the paths to the pages, we can map through the data to get them, and use Route component for each of the path. The Route component accepts two properties, path, where the route will be navigating to, and element, which is a component that will be rendered in that page / route.

Now, we need to add the basic styling to our app. These styles only define the layout of our app. Replace the code in src/App.css with the following code:

Note: We can also create some of the styling using styled-components. You can do the styling however you like, but here, I have used css for basic styling.

/* src/App.css */
* {
  margin: 0;
  padding: 0;
  -webkit-box-sizing: border-box;
  box-sizing: border-box;
  outline: none;
  border: none;
  text-decoration: none;

  font-family: "IBM Plex Sans", -apple-system, BlinkMacSystemFont, "Segoe UI",
    "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue",
    sans-serif;
}

#main {
  width: 100%;
  height: 100%;
  display: flex;
  flex-direction: row;
}

.btn {
  margin: 1rem 1rem 0 0;
  padding: 0.25rem 0.5rem;
  display: flex;
  gap: 0.25rem;
  align-items: center;
  justify-content: center;
  background: transparent;
  outline: none;
  border: 1px solid #808080;
  border-radius: 3px;
  -webkit-border-radius: 3px;
  -moz-border-radius: 3px;
  -ms-border-radius: 3px;
  -o-border-radius: 3px;
  cursor: pointer;
  transition: all 0.2s ease-in-out;
  -webkit-transition: all 0.2s ease-in-out;
  -moz-transition: all 0.2s ease-in-out;
  -ms-transition: all 0.2s ease-in-out;
  -o-transition: all 0.2s ease-in-out;
}

.btn:hover {
  background-color: #e4e3e34d;
}

#page {
  display: flex;
  align-items: center;
  justify-content: center;
  text-align: center;
  text-transform: capitalize;
  font-size: 1rem;
  overflow: hidden;
}

@media screen and (min-width: 468px) {
  #page {
    font-size: 3rem;
  }

  .btn {
    padding: 0.5rem 0.75rem;
    gap: 0.5rem;
  }
}

.app__brand__text {
  font-size: 2rem;
  font-weight: 700;
  color: #5a8dee;
  margin-left: 0.5rem;
}

/* Sidebar toggle button starts */
.outer__circle {
  position: relative;
  width: 1.5rem;
  height: 1.5rem;
  border-radius: 50%;
  background-color: #5f97ef;
  display: flex;
  align-items: center;
  justify-content: center;
}

.outer__circle::after {
  position: absolute;
  top: 0.225rem;
  left: 0.215rem;
  content: "";
  width: 1.1rem;
  height: 1.1rem;
  border-radius: 50%;
  background-color: #fff;
}

.inner__circle {
  position: relative;
  width: 0.75rem;
  height: 0.75rem;
  border-radius: 50%;
  background-color: #5f97ef;
  z-index: 100;
}

.inner__circle::after {
  position: absolute;
  top: 0.125rem;
  left: 0.15rem;
  content: "";
  width: 0.5rem;
  height: 0.5rem;
  border-radius: 50%;
  background-color: #fff;
}
/* Sidebar toggle button ends */

Here, we are resetting every style in the react app using * pseudo selector to configure the whole app the way we want it. Moreover, we are also defining the styles for parent div container of app with the class name main. We are also defining the styles for a button which will be used later in DynamicItem component.

In this global styles file, we are manually making two circles button instead of using some library. This button toggles whether or not to display the sidebar as a whole. This could done in many ways, this is just one of them.

Let's create a file which will store the icons which will be used in our react app.

Head to src folder and create a new folder inside it under components name. Inside components folder, create a new file with Icons.js name and add the following code to it:

// src/components/Icons.js
import HomeOutlinedIcon from "@mui/icons-material/HomeOutlined";
import WebOutlinedIcon from "@mui/icons-material/WebOutlined";
import CalendarTodayOutlinedIcon from "@mui/icons-material/CalendarTodayOutlined";
import CalendarMonthOutlinedIcon from "@mui/icons-material/CalendarMonthOutlined";
import PersonOutlineOutlinedIcon from "@mui/icons-material/PersonOutlineOutlined";
import SubjectOutlinedIcon from "@mui/icons-material/SubjectOutlined";
import GppGoodOutlinedIcon from "@mui/icons-material/GppGoodOutlined";
import AdminPanelSettingsOutlinedIcon from "@mui/icons-material/AdminPanelSettingsOutlined";
import ListAltOutlinedIcon from "@mui/icons-material/ListAltOutlined";
import InputOutlinedIcon from "@mui/icons-material/InputOutlined";

import ArrowRightOutlinedIcon from "@mui/icons-material/ArrowRightOutlined";
import ArrowBackIcon from "@mui/icons-material/ArrowBack";

export {
  HomeOutlinedIcon as HomeIcon,
  WebOutlinedIcon as LayoutIcon,
  CalendarMonthOutlinedIcon as CalendarIcon,
  PersonOutlineOutlinedIcon as UserIcon,
  SubjectOutlinedIcon as InvoiceIcon,
  GppGoodOutlinedIcon as RolesIcon,
  CalendarTodayOutlinedIcon as PagesIcon,
  AdminPanelSettingsOutlinedIcon as AuthIcon,
  ListAltOutlinedIcon as WizardIcon,
  InputOutlinedIcon as ModalIcon,
  ArrowBackIcon,
  ArrowRightOutlinedIcon as ArrowIcon,
};

In this file, we are importing every icon, that we will be using inside our app, and exporting it from a single file. This will help us to import our icons from a single file instead of using multiple lines to import our icons.

Similarly, we will be creating a new file inside src/components folder under the name Data.js. This file will contain our dummy data that we will be using in our app. Open Data.js file and add the following code to it:

// src/components/Data.js
import {
  HomeIcon,
  LayoutIcon,
  CalendarIcon,
  InvoiceIcon,
  UserIcon,
  RolesIcon,
  PagesIcon,
  AuthIcon,
  WizardIcon,
  ModalIcon,
} from "./Icons";

export const SIDEBAR_DATA = [
  {
    id: 1,
    name: "dashboards",
    path: "dashboards",
    icon: <HomeIcon />,
  },
  {
    id: 2,
    name: "layouts",
    path: "layouts",
    icon: <LayoutIcon />,
  },
  {
    id: 3,
    name: "calendar",
    path: "calendar",
    icon: <CalendarIcon />,
  },
  {
    id: 4,
    name: "invoice",
    path: "invoice",
    icon: <InvoiceIcon />,
  },
  {
    id: 5,
    name: "users",
    path: "users",
    icon: <UserIcon />,
  },
  {
    id: 6,
    name: "roles & permissions",
    path: "roles",
    icon: <RolesIcon />,
  },
  {
    id: 7,
    name: "pages",
    path: "pages",
    icon: <PagesIcon />,
  },
  {
    id: 8,
    name: "authentication",
    path: "authentication",
    icon: <AuthIcon />,
  },
  {
    id: 9,
    name: "wizard examples",
    path: "wizard",
    icon: <WizardIcon />,
  },
  {
    id: 10,
    name: "modal examples",
    path: "modal",
    icon: <ModalIcon />,
  },
];

Note that we are importing the icons from a single file instead of using multiple lines to import. This way, we can also avoid redundancy.

In this file, we are defining an array of objects each of which contains data for our pages, i.e. an id, name, path, icon. This is the whole data that will be used throughout our app. Feel free to extend it as much as you want.

Another thing we need to do is create a centralized file which will export all our files, just like Icons.js file. Create index.js file inside src/components folder and add the following code to it:

// src/components/index.js
export { default as Sidebar } from "./Sidebar";
export { default as SidebarItems } from "./Sidebar/SidebarItems";
export { default as DynamicItem } from "./Routes/[item]";

export { SIDEBAR_DATA as dummyData } from "./Data";

In this file, we are following the similar procedure as that of Icons.js.

Note that the files exported as default need to be imported as default as well but the ones without default need to be imported without it.

Now let's create a file that will render the items of a page. You guessed it right! We will be creating DynamicItem component. Create a folder inside src under the name Routes and inside that folder, create a file with [item].jsx and add the following code to it:

If you have worked with NextJS, you know why we are using square brackets. For those who do not know, you can name it anything you want, even without the square brackets.

// src/components/Routes/[item].jsx
import { Link } from "react-router-dom";
import { ArrowBackIcon } from "../Icons";

const Item = (props) => {
  const { page } = props;
  if (page === "homepage") {
    return <div id="page">{page}</div>;
  } else {
    return (
      <div id="page">
        <Link to="/">
          <button className="btn">
            <ArrowBackIcon /> Back to Home
          </button>
        </Link>
        {page}
      </div>
    );
  }
};

export default Item;

We know we have created the routes for the pages that we want. Now we need to make pages that will be rendered.

Here we are importing Link component from react-router-dom, a back icon from Icons.js file. We know there is no other page / route behind it but the homepage contains other pages / routes. So, if the route is /, we just need to render the component, else, we also need to render a back button that will take us back to homepage.

We are using Link component to navigate back to homepage as the page already exists. Recall that we created routes inside src/App.js.

Now comes the main item, the sidebar component. Head to src folder and create a new folder inside it under the name Sidebar and create a new file inside it with index.jsx name. This will be the main file that will consume almost all the files. Add the following code to it:

// src/components/Sidebar/index.jsx
import React, { useState } from "react";

import {
  Children,
  SidebarContainer,
  SidebarWrapper,
  SidebarLogoWrapper,
  SidebarLogo,
  SidebarBrand,
  SidebarToggler,
} from "./SidebarStyles";
import BrandLogo from "./BrandLogo.svg";

import { SidebarItems } from "..";

const MOBILE_VIEW = window.innerWidth < 468;

export default function Sidebar({ children }) {
  const [displaySidebar, setDisplaySidebar] = useState(!MOBILE_VIEW);

  const handleSidebarDisplay = (e) => {
    e.preventDefault();
    if (window.innerWidth > 468) {
      setDisplaySidebar(!displaySidebar);
    } else {
      setDisplaySidebar(false);
    }
  };

  return (
    <React.Fragment>
      <SidebarContainer displaySidebar={displaySidebar}>
        <SidebarWrapper>
          <SidebarLogoWrapper displaySidebar={displaySidebar}>
            {/* Logo wrapper starts */}
            <SidebarLogo href="#">
              <span className="app-brand-logo demo">
                <img src={BrandLogo} alt="Brand logo" />
              </span>
              <SidebarBrand
                displaySidebar={displaySidebar}
                className="app__brand__text"
              >
                Frest
              </SidebarBrand>
            </SidebarLogo>
            {/* Logo wrapper ends */}
            {/* Toggle button */}
            <SidebarToggler
              displaySidebar={displaySidebar}
              onClick={handleSidebarDisplay}
            >
              <div className="outer__circle">
                <div className="inner__circle" />
              </div>
            </SidebarToggler>
          </SidebarLogoWrapper>
            {/* Render the SidebarItems component */}
          <SidebarItems displaySidebar={displaySidebar} />
        </SidebarWrapper>
      </SidebarContainer>
            {/* Render the children */}
      <Children displaySidebar={displaySidebar}>{children}</Children>
    </React.Fragment>
  );
}

This is the file where we will be building Sidebar. We are importing state manager useState from React to control the view of the sidebar, styles from another file, it will be created within the same directory, a Brand Logo Feel free to use whatever logo you want, SidebarItems file that will render our items from the data.

Another thing we are doing here is creating a global variable that will store whether the viewpoint is mobile or not. If the viewpoint is mobile, display a portion of the sidebar otherwise, make the sidebar togglable, using useState. Then we are creating an arrow function that will handle whether or not to display the full sidebar.

In the end, we are returning a React Fragment and displaying the brand logo, toggle button, the sidebar items, and the children.

Note that we are creating the styles using styled-components that can accept parameters and will help us in displaying the sidebar.

Now let's create a file that will apply all the necessary styling to the sidebar. Head to src/components/Sidebar and create a new file under the name SidebarStyles.js and add the following code to it:

// src/components/Sidebar/SidebarStyles.js
import styled from "styled-components";

// Children Component
export const Children = styled.div`
  width: 100%;
  height: 100%;
  margin-left: ${({ displaySidebar }) => (displaySidebar ? "15rem" : "5rem")};
  @media (max-width: 468px) {
    margin-left: 5rem;
  }
`;

export const SidebarWrapper = styled.div`
  width: 100%;
  height: 100%;
  display: flex;
  flex-direction: column;
  font-size: 0.9rem;
`;

export const SidebarLogoWrapper = styled.div`
  padding: 0.5rem 1rem;
  margin-bottom: 1rem;
  display: flex;
  justify-content: ${({ displaySidebar }) =>
    displaySidebar ? "space-between" : "center"};
  align-items: center;
  @media (max-width: 468px) {
    justify-content: center;
  }
`;

export const SidebarLogo = styled.a`
  display: flex;
  align-items: center;
  justify-content: center;
  @media (max-width: 468px) {
    display: none;
  }
`;

export const SidebarBrand = styled.span`
  display: ${({ displaySidebar }) => (displaySidebar ? "block" : "none")};
`;

export const SidebarToggler = styled.button`
  cursor: pointer;
  display: ${({ displaySidebar }) => (displaySidebar ? "block" : "none")};
  @media (max-width: 468px) {
    display: block;
  }
`;

// SidebarItem styles
export const ItemsList = styled.ul`
  list-style: none;
`;

export const ItemContainer = styled.li`
  margin-top: 0.5rem;
  width: 100%;
  padding: 0.5rem 0.25rem;
  border-radius: 0.2rem;
  cursor: pointer;
  &:hover {
    background: #eaeced;
  }
  &.active {
    background-color: #dbe4f3;
  }
`;

export const ItemWrapper = styled.div`
  display: flex;
  align-items: center;
  color: #7c7788;
`;

export const ItemName = styled.span`
  margin-left: ${({ displaySidebar }) => (displaySidebar ? "0.5rem" : "0")};
  display: ${({ displaySidebar }) => (displaySidebar ? "block" : "none")};
  text-transform: capitalize;
`;

// Sidebar Container
export const SidebarContainer = styled.div`
  position: absolute;
  left: 0;
  width: ${({ displaySidebar }) => (displaySidebar ? "15rem" : "5rem")};
  height: 100vh;
  padding: 0.75rem;
  background: #f3f4f4;
  transition: width 350ms ease;
  border-right: 1px solid #d4d8dd;
  overflow-x: hidden;
  ${({ displaySidebar }) =>
    displaySidebar && "box-shadow: 8px 0px 12px 0px rgba(0,0,0,0.1)"};
  ${ItemWrapper} {
    justify-content: ${({ displaySidebar }) => !displaySidebar && "center"};
  }
  &:hover {
    ${({ displaySidebar }) =>
      !displaySidebar && "box-shadow: 8px 0px 12px 0px rgba(0,0,0,0.1)"};
    @media (min-width: 468px) {
      width: ${({ displaySidebar }) => !displaySidebar && "15rem"};
      ${SidebarLogoWrapper} {
        justify-content: ${({ displaySidebar }) =>
          !displaySidebar && "space-between"};
      }
      ${SidebarBrand} {
        display: ${({ displaySidebar }) => !displaySidebar && "block"};
      }
      ${SidebarToggler} {
        display: ${({ displaySidebar }) => !displaySidebar && "block"};
      }
      ${ItemWrapper} {
        justify-content: ${({ displaySidebar }) =>
          !displaySidebar && "flex-start"};
      }
      ${ItemName} {
        display: ${({ displaySidebar }) => !displaySidebar && "block"};
        margin-left: ${({ displaySidebar }) => !displaySidebar && "0.5rem"};
      }
    }
  }
  ::-webkit-scrollbar {
    width: 4px;
    height: 3px;
  }
  ::-webkit-scrollbar-track {
    border-radius: 10px;
    background-color: transparent;
  }
  ::-webkit-scrollbar-thumb {
    border-radius: 10px;
    background: #eaeced;
    &:hover {
      background: #d5e0f3;
    }
  }
  @media (max-width: 468px) {
    width: 5rem;
  }
`;

Here we are making the styles according to the state that we created inside Sidebar.jsx. Recall that we passed the parameters to these components. We can use those params to display and hide whatever we want.

Note the hierarchy. In order to control a child component from a parent component, the child component need to be declared before the parent component.

Now then, let's create a file that will render all the items of Sidebar. Inside the same directory, create a new file under the name SidebarItems.jsx and add the following code to it:

// src/components/Sidebar/SidebarItems.jsx
import React, { useState } from "react";
import { Link } from "react-router-dom";
import {
  ItemsList,
  ItemContainer,
  ItemWrapper,
  ItemName,
} from "./SidebarStyles";

import { dummyData } from "..";

const SidebarItems = ({ displaySidebar }) => {
  const [activeItem, setActiveItem] = useState(0);

  return (
    <ItemsList>
      {dummyData.map((itemData, index) => (
        <ItemContainer
          key={index}
          onClick={() => setActiveItem(itemData.id)}
          {/* Adding active class when the user clicks */}
          className={itemData.id === activeItem ? "active" : ""}
        >
          <Link to={itemData.path}>
            <ItemWrapper>
              {itemData.icon}
              <ItemName displaySidebar={displaySidebar}>
                {itemData.name}
              </ItemName>
            </ItemWrapper>
          </Link>
        </ItemContainer>
      ))}
    </ItemsList>
  );
};

export default SidebarItems;

In this file, we are using useState to manage the active item of the sidebar, Link from React Router to redirect the user to the page, the dummy data from src/components/index.js, and the styles from src/components/Sidebar/SidebarStyles.js.

Inside the main function, we are creating a list and inside the list, we are mapping through the dummy data and rendering it using the styled components that we have imported. Note that we also created an active pseudo-selector inside SidebarStyles.js, that will style the item that is active. The active class is added to the item only if the user clicks it.

Here, we are also using the Link component of React Router, for each item, to navigate to the item that the user clicks.

Finally, we have the following output. Play with the code however you wish and see the changes.

This is a simple Sidebar component. You can, however, extend it and make it much more amazing however you demand it.

Resources:

Stay tuned with more of my blogs on my site

This is my first blog, so, there will be some mistakes in the script, however, the code works perfect. Kindly share tips that can help me make the articles more organized.

Websites images

JealousGx — Mon, 24 May 2021 15:51:38 +0000

https://react-projects.netlify.app
In the above website, the websites are collectively shared. I wanted to know if the shared websites' images were taken manually or there is something going on in the backend that automatically takes the images and posts them here. Like in the image below, netlify is actually taking pictures automatically from the published websites:

https://user-images.githubusercontent.com/59867217/119329279-e66d1b80-bc39-11eb-8734-330ddd71f080.png