
As a software developer with little background in design and color theory, you might find yourself tasked with creating visually appealing web pages. Without a solid foundation in design principles, especially color theory, this can seem daunting. You might wonder how to quickly and effectively choose colors that create a cohesive and aesthetically pleasing design. I'll explore how I used AI, specifically ChatGPT-4o, to solve this problem by leveraging color theory principles to generate color schemes mathematically.

As a developer with a background in art, I've always relied on traditional watercolor theory to create visually striking color palettes. The theory is simple: take your primary color, find its contrasting color, and mix the two to get a neutral tone. This neutral tone helps other colors pop on the canvas or page. However, applying this theory to website design can be challenging, especially for those without an art background. I wondered if there was a mathematical way to reproduce these watercolor results using hex codes, making the process more accessible for everyone.

I started with a watercolor study, using an orange as my primary color and blue as its contrasting color. By mixing these two, I obtained a neutral tone. I scanned these watercolor samples and used an eye dropper tool to extract their hex codes. With these hex codes, I styled a dummy app, incorporating the primary color, complementary color, and neutral tones for text and drop shadows.
<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/Pallette.png" alt="Colors" style="display: block; max-width: 100%;">
<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/Headers.png" alt="Headers" style="display: block; max-width: 100%;">

Next, I turned to ChatGPT. I provided it with the hex codes: the starting color (orange), the contrasting color (blue), and the neutral tone obtained from my watercolor study. My goal was to see if ChatGPT could replicate this process mathematically.

Initially, ChatGPT calculated the contrasting color and the neutral tone. However, the neutral tone was always a perfect gray (hex code: #888888), which didn't match the nuanced neutral tones I observed in my watercolor samples. I realized that the mathematical approach needed refinement to account for the blending of colors in a more realistic manner, since with this mathematical approach the exact contrasting color was achieved every time, which, in color theory, means that the neutral tone will always be a perfectly neutral gray.

I queried ChatGPT to explore if using light filters or different blending techniques could achieve a more accurate neutral tone. This led to the discovery of alpha blending, which involves overlaying colors with varying transparency levels. By applying a 60% filter for the primary color and a 40% filter for the contrasting color, I achieved a neutral tone that leaned more towards the primary color, mimicking the watercolor effect.

<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/equation.png" alt="equation" style="display: block; max-width: 100%;">

With this refined approach, I developed an equation where I input a single color, and ChatGPT calculates the complementary and neutral tones. This method allows me to create harmonious color palettes mathematically, making the process accessible to those without an art background. For example, in a scenario where a client's logo color is orange, I can now generate a visually appealing color scheme for their website with ease.

<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/colors.png" alt="equation" style="display: block; max-width: 50%;">
<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/Headers2.png" alt="Headers2" style="display: block; max-width: 100%;">

Traditionally, determining color themes relied heavily on artistic intuition and manual blending techniques. While effective, this approach can be challenging for those without a strong art background. By leveraging AI and mathematical principles, we can automate and simplify this process, making it accessible to developers without design teams or time to get a Master's in Fine Art. This new approach not only saves time but also ensures consistency and accuracy in color theme generation for websites. And it's fun!



You might wonder how to quickly and effectively choose colors that create a cohesive and aesthetically pleasing design. I'll explore how I used AI, specifically ChatGPT-4o, to solve this problem by leveraging color theory principles to generate color schemes mathematically.

Using AI To Create Website Color Themes


At Olio Apps we understand the challenges organizations adopting cloud for the first time or experimenting with serverless development run into when it comes to designing and deploying scalable and cost effective architecture on AWS.

Seldom does an organization have the time and resources to commit to learning a new tech stack while developing features.

At Olio Apps we regularly support clients who are in need of talent specialized in specific AWS services who can disperse that knowledge throughout the organization.

This is why we support our team members in developing their knowledge of cloud and serverless best practices when it comes to AWS Infrastructure.

Today, we are excited to announce and celebrate Aaron Whitaker’s recent AWS Solutions Architect Certification.

The AWS Solutions Architect Certification validates proficiency in designing and deploying scalable and cost-efficient cloud solutions on AWS. Individuals with this expertise are able to tailor AWS infrastructure to an organization’s needs while optimizing performance and cost-effectiveness. Additionally, those who achieve AWS Certification in general can be assured they are up to date with Amazon’s best practices and innovation standards.

## AWS Solutions Architect Associate Bolsters Technical Abilities

Aaron found that the process of studying and learning for the AWS Solutions Architect Certification exam reinforced his practical knowledge while exposing him to additional best practices:

> Getting the solutions architect certification helped to reinforce the knowledge I’ve gained through practical experience working in AWS for the past two years. It also gave me more insight into best practices and patterns I hadn’t previously known about. It's given me more confidence to design well-architected cloud systems

Aaron is a Fullstack Engineer at Olio Apps who specializes in fullstack and serverless applications. You can learn more about the team at Olio Apps <a href="https://www.olioapps.com/team">here.</a>

Congratulations again Aaron, we are excited to see how this new knowledge from the AWS Solutions Architect Certification encourages your further learning.


At Olio Apps we acknowledge that Amazon Web Services (AWS) is an industry leader when it comes to providing reliable and scalable cloud services for companies across all domains.

Celebrating Aaron Whitaker’s AWS Solutions Architect Certification


At Olio Apps EventBridge has become a huge topic of conversation ever since we’ve been using it with one of our clients. Initially, our client’s architecture followed a synchronous inline model where you give the server a request and then it does A, B, C, D, and E.

As the app continues to grow, it becomes harder to manage all of these different threads and if-thens. So we've shifted to utilize AWS event-driven architecture, a first for this client. Initially, we integrated with SQS queues (Amazon Simple Queuing Service) to manage asynchronous job processing. Since then we have begun to shift more and more to event driven architecture patterns.

## Facilitating Event Driven Architecture Evolution using Amazon EventBridge

Some of you may recognize this paradigm. Initially, we needed to trigger notifications based on specific factors like the day of the week, how long it had been since a certain event happened, or a user’s relationship to one another.

So we began to utilize a serverless event bus, Amazon EventBridge, to listen, schedule, & trigger these events. EventBridge Listener would wait for specific events to enter the event bus. Once they did, this would trigger a corresponding lambda function to take the event to an SQS queue where it would then be processed asynchronously.

The above description is essentially the base use case described by AWS’ official illustrations. This image shows the event bus and the different events being pumped into it from specific sources.

<img src="/assets/blog/2024-09-04-facilitating-event-driven-architecture-evolution-using-amazon-eventbridge/eventbridgediagram.png" alt="EventBridge Diagram" style="display: block; max-width: 100%;">

And as stated in <a href="https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event-list.html">AWS’ documentation</a> EventBridge can handle input from a variety of AWS sources or from a custom event bus.

In particular, we provisioned our AWS resources using the serverless framework and used a combination of EventBridge’s rules, event matching, and routing capabilities to enable a user experience informed by the context of these specific events.

## Value of Eventbridge

In summary this is how EventBridge functions as we have events flowing into the pipeline with the following orchestration.

**Rules**: We define rules within EventBridge that act as event filters. These rules can listen for specific events, like "user created" or "user updated."

**Event Matching**: Each rule is configured with an event pattern. This pattern specifies the data characteristics and the rule it is looking for. For instance, a rule might match events where the "detail-type" property equals "user-updated" and the "source" property equals "staging-API."

**Routing Events**: When an event matches a rule's pattern, EventBridge routes it to a designated target. This target can be a Lambda function that we've previously defined to handle the event.

Imagine a rule named "user-updated-event-bridge-rule." This rule intercepts events flowing through the pipeline, searching for events that match its criteria (detail-type="user-updated" and source="staging-API").
If an event doesn't match, it's simply passed along. However, if a match occurs, the event is directed to the Lambda function associated with that rule. This Lambda function executes the desired logic based on the received event data.

A major reason EventBridge has been so valuable for our client’s event driven architecture is because of EventBridge’s robust flexibility, including:

**Multiple Rules per Event**: A single event can be matched by multiple rules, allowing for diverse processing paths.

**Multiple Targets per Rule**: Each rule can route events to up to five different targets, enabling parallel processing or sending events to various services.

**Event Data**: We can include any relevant data within the event itself. This allows Lambda functions to perform actions based on the differences between old and new data (e.g., detecting a user's change in profile information).

This ability to define custom rules and targets empowered us to make intricate event workflows that fit our client’s needs. Currently, we have Lambda functions that trigger additional events based on the processed data, sending them back into the EventBridge pipeline for further processing of 3rd party APIs. This is one example where we are able to leverage the vast capabilities of EventBridge for enabling event driven architecture. for building sophisticated event-driven architectures using EventBridge.

Overall, this EventBridge architecture has allowed us to offload all these semi-heavy computational side effects when there is a profile update to the cloud. So we're not taking a bunch of performance hits by running everything in line on individual requests.

We hope you enjoyed our discussion on how Olio Apps is utilizing EventBridge to meet customer needs using event driven architecture on AWS. If you have any questions about using EventBridge yourself or have any questions about how your application may be able to utilize EventBridge, please don’t hesitate to contact us.


At Olio Apps, EventBridge has become a huge topic of conversation ever since we’ve been using it with one of our clients. As the app continues to grow in complexity and perform more complex functions, it becomes harder to manage all of these different threads and if-thens

Facilitating Event Driven Architecture Evolution Using Amazon EventBridge


When prototyping, designing, and building software applications for clients it’s essential to have a firm grasp on emerging technology. However, technology itself is seldom what drives value for a business; it’s knowing how, when, and where to apply the technology in question that brings maximum value. 

At Olio Apps, we value the skillful application of emerging technology to SMB and enterprise business problems and that’s why we encourage our team members to continually expand their knowledge in all areas of software development.

This is why we are excited to announce and celebrate today Dustin Herboldshimer’s recent AWS Technical Accreditation.

The AWS Technical Accreditation provides training and assessment opportunities for individuals to demonstrate their proficiency in implementing AWS services, solutions, and best practices. It covers a range of topics related to AWS cloud computing, including architecture, security, operations, and migration.

## AWS Technical Accreditation Bolsters Technical Abilities

Dustin has found the process of studying and learning for his accreditation meaningful:

> Through my AWS Technical Accreditation course, I gained a deeper understanding of the full range of AWS services and their applications. I also learned more about the significant business benefits of adopting serverless technologies, enhancing my ability to prescribe efficient and innovative cloud solutions based on customer requirements.

Dustin is one of our Engineering Managers and developers focused on React Web Applications and Full Stack Development. You can learn more about the team at Olio Apps here.

Congratulations again Dustin and we encourage you to continue developing your breadth of expertise. 


Celebrating Dustin Herbolshimer’s AWS Technical Accreditation


At Olio Apps we acknowledge that Amazon Web Services (AWS) is an industry leader when it comes to providing reliable and scalable cloud services for companies across all domains.

Knowing this, we make it our mission to support our team members in growing their knowledge base and expertise regarding the suite of AWS services and use cases so we can suggest the best practices and architectures when it comes to solving client problems. This is why we are excited to announce and celebrate Laurie Waller’s recent AWS Developer Associate Certification.

The AWS Developer Associate certification validates expertise in developing cloud-based applications on AWS and ability to design, develop, and deploy applications on AWS. Those who achieve an AWS Certification can be assured they are up to date with Amazon’s best practices and innovation standards.

## AWS Developer Associate Bolsters Technical Abilities

Laurie found that the process of studying and learning for the AWS Developer Associate exam bolstered her technical skills:

> Securing the AWS Developer Associate certification significantly enhanced my proficiency in deploying, managing, and operating scalable systems on AWS. It not only bolstered my technical skills but also built up my strategic approach to cloud solutions, fostering both personal and professional growth and ensuring our team can deliver top-notch results...

Laurie is a Fullstack Engineer at Olio Apps and a self described lifelong learner. You can learn more about the team at Olio Apps here.

Congratulations again Laurie, we are happy to hear you learned so much by studying for your AWS Developer Associate Certification.


Celebrating Laurie Waller’s AWS Developer Associate Certification


Since the launch of serverless AWS services in 2006 with S3 and general availability of AWS Lambda in 2015 there has been steady adoption of serverless architectures across all industry verticals.

Building serverless applications alongside our SMB and enterprise clients, we at Olio Apps have seen a clear differentiator between an organization that skillfully applies serverless best practices on AWS and those that don’t. Those that do are able to maximize the agility, scalability, and cost-effectiveness of AWS architectures.

This isn’t surprising. As when it comes to the market share of Cloud Service Providers, AWS is still the leader in 2024 due to the benefits its infrastructure provides.

Getting to serve clients during these critical moments of prototyping, architecture design, and development with our serverless expertise and experience is a key pillar of pride and motivation for our organization.

“Olio Apps successfully delivered a functioning product, which received positive feedback on its quality, stability, and ease of use. The team delivered on time and within budget and worked in sprints to ensure a seamless workflow. They impressed with their flexibility and prototyping skills” -Trevor Dryer, CEO Carbon Title

In light of this, we see the general availability of Amazon Bedrock as the next wave of highly impactful and influential services offered by AWS. Amazon Bedrock represents a paradigm shift where all companies have access to the possibility of accelerating the performance of their organization with high-performing foundational models of leading AI companies.

However, like with serverless, for companies to maximize the benefits of Generative AI they select the right technology for the job and have the knowledge, experience and expertise to implement the technology correctly.

This can prove challenging since the field of Generative AI is relatively new and growing in popularity. Its novelty means that true Generative AI development expertise is scarce and choosing technical decisions because they are popular and not the best solution can become a costly mistake.

That is why we have decided to grow our partnership with Amazon Web Services through the Amazon Partner Network, focusing on designing, prototyping, and building Generative AI solutions with Amazon Bedrock and serverless development on AWS.

We aim to offer our seasoned leadership to companies having to make critical decisions regarding the use of Generative AI and serverless infrastructure to achieve their business goals.

In step with this commitment, we are empowering our team to invest in their education and knowledge base in the areas of Generative AI and serverless infrastructure on AWS.

Today we are honored and excited to announce that seven of our team members have already taken charge and received Accreditation and Certification from AWS in Q1.

Congratulations to Laurie Walker, Dustin Herboldshimer, Aaron Whitaker, Aron Glenn, Scott Becker, Aron Racho, and Joshua Proto for their recent achievements.

At Olio Apps we value a growth mindset that supports continuous learning and development. Having knowledge is essential to ensure the experience driven execution of mission critical projects.

Whether an organization is considering implementing Amazon Bedrock or serverless for the first time, or looking to scale their usage of these services on AWS, Olio Apps looks forward to being your trusted technology partner.


We have decided to grow our partnership with Amazon Web Services through the Amazon Partner Network, focusing on designing, prototyping, and building Generative AI solutions with Amazon Bedrock and serverless development on AWS.

Olio Apps Commits to AWS Partnership in 2024


This is a collection of techniques and tools we use at Olio Apps to make UI application development faster and more efficient!

## Atomic Design
https://bradfrost.com/blog/post/atomic-web-design/

The UI is an aggregation of discrete, composable components. These components are concerned *only* with presentation, eg. styling and content -- not logic.
- Smallest reusable elements are called Atoms
- They are designed to be generally agnostic of their environment

Atomic components have well defined contracts (eg. props). This expands to their containers.

Global atoms are composed into global, reusable molecules. Global atoms and molecules form the basis of feature-specific Molecules and Atoms. Molecules and Atoms are composed into pages

### Why?

- Separation of concerns -- you can focus on a single domain and be maximally effective
- Reuse -- need to "bless" every button in the app with a spinner? Update the basal Atom for it
- Parallelization -- folks can be divided into focusing on the pure presentational UI components, while others work on the "logic" pieces
- You can use storybook. More on this below

## Storybook

https://storybook.js.org/

Storybook is a rapid-development environment for pure presentation components. It is a framework for exercising / displaying all the behavioral variations for components as controlled by their props.

### Why?

- With storybook, you get an immediate feedback on the components as they are developed
- No need to "hack" the live environment that the components are going to be used in
- Sometimes there is NO live environment yet -- but you will not be blocked because you can use storybook to view your components
- Storybook is to UI component development as test-driven unit-test development is to non-ui component development
- Developers can use storybook to interact with the design team, publishing the full range and variation of components in an easy to access way
  - You don't need to seed an environment to show all the permutations of particular components and even whole pages
  - Designers can easily manipulate the storybook to see what things look like by simulating conditions such as size of that page, values of the props

## TypeScript

https://www.typescriptlang.org/

TypeScript is JavaScript 2.0 -- a strongly typed flavor of JavaScript. It can be incrementally added to a pure-JavaScript environment.

### Why?

Compile-time checking of errors. In larger apps, sometimes you will only know that a shape going into a function is incorrect once its in production.

Contract-driven development. Think of types will get developers to start thinking and planning about how pieces interact, first at the function level; next at the module level; finally at the systems level.

Without types, you can only know what the "valid" shape of an object is from its consumers.

- There are infinitely more consumers, and they change all the time
- Without a type or interface, I would have to inspect ALL the consumers of an object to know what its valid attributes are!
- Without types you cannot efficiently describe how a system interacts with itself, or other systems

## Redux

https://redux.js.org/

Redux is global state management for large scale appplications.

### Why?

Larger scale UIs often need to cache server side state. For example:

- Logged in user
- Incoming unread chat notifications
- Synced media

It is useful to cache this state because you don't want to pull it down all the time. If your app is going to work offline sometime, caching the data from disk in memory in redux is often useful. When some region in that state tree is changed, other interested parts of the UI can "listen" and react to those changes.

[Redux toolkit](https://redux-toolkit.js.org/) and Olio's own [Sitka framework](https://github.com/olioapps/sitka) are syntactic sugar built atop redux

## UI Backend Modularization

Just as the pure presentational components are organized into modules of specific Atoms, Molecules, and Pages. The "backend" of the frontend is also separated out into modules by feature/responsibility area. These pieces are NOT concerned with presentational concerns But are instead concerned with:

- Navigation (routing)
- Interaction with the API
- Interaction with the device (local storage, services such as bluetooth, push notifications, etc)

Modules are concerned with the management of their particular subslice of the global state (or have their own private state); and the operations against that state -- and nothing else.

### Why?

Parallelization

- Folks can work on and concentrate on the "backend" of the app while others work on the frontend
- Folks can work on different feature modules within the backend tree

Separation of concerns

- The logical and UI layers can change without breaking each other
- The backend feature modules are less likely to have regressions when they change, as their logic is self contained with the module

Reuse

- The backend modules may reuse each other using well defined contracts
- For instance we can have a module purely concerned with activity tracking
- That can be integrated with the navigation module which can record activity using the aforementioned module

Testability

- The entire functionality of a logical feature / module is easily unit testable because its possible to mock their state without having to mock out the rest of the system

## Sitka

https://github.com/olioapps/sitka

Sitka is an opinionated framework built atop of Redux and Redux Saga. It encapsulates UI backend modules into classes that control both state and operations of those modules.

### Why?

Sitka ticks all the items of the UI Backend Modularization section. You can safely modify module state via callbacks from the UI.

Sitka implements pub-sub mechanism:

- One module does something
- Other modules can "subscribe" and react to those

Sitka implements background "jobs" - recurring polling tasks.

Sitka is very powerful, and has been implemented in 10+ projects across multiple customers. Alternatives include redux toolkit.

## Summary

This collection of tools and techniques forms the basis for fast productive UI development projects at Olio Apps. We continue to iterate and build on our toolset every day.


This is a collection of techniques and tools we use at Olio Apps to make UI application development faster and more efficient!

UI Architecture Powerups - What, and Why


![Stairs](/assets/blog/2021-04-14-practical-recursion-with-react-components/recursion.jpg)

## What Is Recursion, and When Is It Useful?

In computer science, recursion is a key programming technique in which a function calls itself one or more times until a specific condition is met. It can be particularly useful when working with deeply nested structures that prove too complex for an iterative solution.

Though recursion seldom appears in an average programmer's day-to-day work, there are real-world use cases in frontend web applications, like the one we'll go over here.

## A Practical Use for Recursion in React

My team was tasked with putting together a reusable, infinitely nested tree component. The nested data structure coupled with infinite depth presented an opportunity for a recursive approach. Follow along to understand the ins and outs of a working React Tree component powered by recursion + React rendering.

Giving our component nested data in the following shape, we’ll now have a functioning, modular, and recursive component ready for use!

```typescript
interface TreeBranch {
  readonly id: string
  readonly label: string
  branches?: Tree
  readonly selected?: boolean
}

type Tree = ReadonlyArray<TreeBranch>

const mockOrgTreeList: Tree = [
  {
    label: "Liberty Health",
    id: "1",
    branches: [
      {
        label: "Pacific Northwest",
        id: "2",
        branches: [
          {
            label: "East Portland Clinic",
            id: "3",
            branches: [],
          },
          {
            label: "Beaverton / Tigard",
            id: "4",
            branches: [],
          },
          {
            label: "Lake Oswego Regency",
            id: "5",
            branches: [],
          },
        ],
      },
      {
        label: "Alaska",
        id: "6",
        branches: [],
      },
    ],
  },
  {
    label: "Northstar Alliance",
    id: "7",
    branches: [
      {
        label: "Chicago",
        id: "8",
        branches: [
          {
            label: "Southwest Region",
            id: "9",
            branches: [
              {
                label: "Desplains",
                id: "10",
                branches: [],
              },
              {
                label: "Oak Lawn",
                id: "11",
                branches: [],
              },
            ],
          },
          {
            label: "Northwest Region",
            id: "12",
            branches: [
              {
                label: "East Morland",
                id: "13",
                branches: [],
              },
            ],
          },
        ],
      },
      {
        label: "New York",
        id: "14",
        branches: [
          {
            label: "Manhattan",
            id: "15",
            branches: [],
          },
          {
            label: "Queens",
            id: "16",
            branches: [],
          },
          {
            label: "5372 Arlington Heights",
            id: "17",
            branches: [],
          },
          {
            label: "The Earlmore Institute of Health",
            id: "18",
            branches: [],
          },
        ],
      },
    ],
  },
]
```

The end product:

![Tree gif](/assets/blog/2021-04-14-practical-recursion-with-react-components/tree.gif)

## Building a Reusable Component

First, we’ll import React and create some styled Material UI components.

```typescript
import React, { Fragment, useState } from "react"
import { styled, makeStyles } from "@material-ui/core/styles"
import ExpandMoreIcon from "@material-ui/icons/ExpandMore"
import ChevronRightIcon from "@material-ui/icons/ChevronRight"
import Box from "@material-ui/core/Box"

// styles

const StyledLabel = styled(Box)({
  height: "24px",
  "&:hover": {
    cursor: "pointer",
  },
})
const StyledTreeItem = styled(Box)({
  display: "flex",
  flexDirection: "row",
  alignItems: "center",
})
const StyledTreeChildren = styled(Box)({
  paddingLeft: "10px",
})
```

## Props

Here are the prop shapes that we’ll use to build our components:

```typescript
interface TreeItemProps {
  readonly id: string
  readonly onSelectCallback: (e: React.MouseEvent<HTMLInputElement>) => void
  readonly label: string
  readonly isSelected: boolean | undefined
  readonly children: ReadonlyArray<JSX.Element>
}

interface RecursiveTreeProps {
  readonly listMeta: Tree
  readonly onSelectCallback: (value: TreeBranch) => void
}
```

### TreeItem

This will be our most atomic component, reused anywhere an item is rendered by the data we pass to our tree. This component can contain more of itself in a nested fashion, allowing us to render them recursively.

#### This component needs:

1. **onSelectCallback** - to power what happens when we click the item.
2. **label** - to display names of organizations (in our case).
3. **children** - to display nested items if they exist.
4. **isSelected** - to specify pre-selected items in the fetched data (as opposed to clicking to select the item).

```tsx
const TreeItem = ({
  onSelectCallback,
  label,
  isSelected,
  children,
}: TreeItemProps) => {
  const [isOpen, toggleItemOpen] = useState<boolean | null>(null)
  const [selected, setSelected] = useState(isSelected)

  return (
    <div>
      <StyledTreeItem>
        {children.length > 0 && (
          <Box
            className="icon-container"
            onClick={() => toggleItemOpen(!isOpen)}
          >
            {isOpen ? <ExpandMoreIcon /> : <ChevronRightIcon />}
          </Box>
        )}
        <StyledLabel
          className="label"
          onClick={(e: React.MouseEvent<HTMLInputElement>) => {
            setSelected(!selected)
            onSelectCallback(e)
          }}
          style={{
            marginLeft: `${children.length === 0 ? "24px" : ""}`,
            background: `${selected ? "#d5d5d5" : ""}`,
          }}
        >
          {label}
        </StyledLabel>
      </StyledTreeItem>
      <StyledTreeChildren>{isOpen && children}</StyledTreeChildren>
    </div>
  )
}
```

### Recursive Tree

This will be the workhorse component where our recursive logic lives. We pass our data here through listMeta to recursively render our TreeItem component as follows:

#### This component needs:

1. **listMeta** - the shape of our tree data.
2. **onSelectCallback** - to be passed down to TreeItems.

```tsx
const RecursiveTree = ({ listMeta, onSelectCallback }: RecursiveTreeProps) => {
  const createTree = (branch: TreeBranch) =>
    branch.branches && (
      <TreeItem
        id={branch.id}
        key={branch.id}
        onSelectCallback={(e: React.MouseEvent<HTMLElement>) => {
          onSelectCallback(branch)
        }}
        isSelected={branch.selected}
        label={branch.label}
      >
        {branch.branches.map((branch: TreeBranch) => {
          return <Fragment key={branch.id}>{createTree(branch)}</Fragment>
        })}
      </TreeItem>
    )

  return (
    <Box>
      {listMeta.map((branch: TreeBranch, i: any) => (
        <Box key={i}>{createTree(branch)}</Box>
      ))}
    </Box>
  )
}
```

## Our Functional Tree in Use

Check out the [Github repo here](https://github.com/jIrwinCline/recursive-react-tree).

## Some Final Thoughts

Recursion can be a crafty tool in a developer’s arsenal. But as we build a recursive pattern to have a lot of moving parts, complexity and drawbacks can start to manifest. There’s no magic associated with this concept. Most of the problems that can be solved by recursion are likely able to be solved with iterative loops. When recursive solutions seem tempting, make sure to consider the potential drawbacks.

#### When Not to Use Recursion

There are generally more reasons not to use recursion than to do so. Yes, it can be exciting to delve into an abstract solution, but a good engineer weighs the potential downsides, which we'll go over here.

- Results in code that's harder to read or comprehend

Recursion isn’t a pattern developers come across every day. When implemented, you’re bound to catch future developers off guard, which is a noteworthy downside. Difficulty comprehending the pattern at a later date is likely to occur, not only when teammates peak at the code, but also when you happen to return to your own code six months later.

This can be mitigated by extensively documenting and commenting your code. Explain to future developers (and yourself) why and where recursion occurs. For example, above the function, add a doc comment including an obvious note, such as, "This function is recursive. It calls itself in order to render all descendents." A comment directly above the line where recursion occurs can also be helpful to call out.

- Can make maintenance and debugging a nightmare

Developers maintaining the codebase in the years to come could potentially see this pattern in a bad light. When others (or even you) come back to the code, the recursive solution may not be self-explanatory. If new features need to be added or bugs show up, getting to the bottom of what’s happening may be harder with a pattern like this.

- Can lead to performance issues when processing large amounts of data

Recursion can be a memory-intensive operation with larger data sets. A function repeatedly calling itself will consume more memory when compared to an iterative loop. If your data set is not large, then pay no mind. But if a recursive solution is implemented in an environment where resources are scarce and the data is hefty enough, you could run out of memory.
Recursion can also be slow unless implemented carefully. For example, if each call to the function recomputes some value, but the result is actually the same for every iteration, or the same for each level in the tree, the function will be doing unnecessary repeated computations that could be avoided by applying memoization techniques.

## In the End

There can be good reasons to avoid recursion. But if your case doesn't have any of these red flags and you know your data set will always comfortably fit within your available memory, it can be a great solution to have up your sleeve.


Create a modular and recursively rendering tree component in React

Practical Recursion with React Components


<div style="padding-bottom: 40px; padding-right: 250px; padding-left: 250px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/eagle-wing.png" style="display: block; max-width: 100%;" alt="eagle wing">
</div>

After a long-winded search for employment, including copious rejections, maybe you’ve finally landed a sustainable position at a well-grounded company, or maybe you’re still on the hunt. The job market ebbs and flows, but as long as you stay dedicated with your spirits up, you’ll likely be making this transition as well. I started my journey into tech a year ago, and I’ve now been working as a developer at my newest company, Olio Apps, for about 3 months. After a pretty great interview, I felt confident that I would be offered the position. Soon after, I had a start date to look forward to! As anyone would be, I was excited, but I couldn’t help but be nervous as well. I felt like this was a bigger opportunity than my previous positions at small start-ups.

Throughout these last few months, I’ve learned some things I wish I'd known beforehand, but there have also been things I wish I hadn’t focused on as much. Pulling from my quick onboarding process and other experiences I've had joining teams, I’ve written this guide as a roadmap for new developers, aimed at showing them what to focus on in order to be a successful hire. This "survival guide" should help new developers onboard more effectively, connect with their team in a meaningful way, and focus on the things that matter while joining a new company or team.

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/chicks.jpg" style="display: block; max-width: 100%;" alt="chickling stage">
</div>

## First Day

So it’s your first day of work!

You’ll likely be getting access to the company’s software and email (if not later, depending on the company). You’ll probably be introduced to team members or managers that you’ll be working closely with, then go over your first tasks. Make sure you know what to work on, who to report to, and which tools you’ll need to be an active part of the team. JIRA, Confluence, Slack, and the company Gmail were some of what I was granted access to on my first day.

I expected there to be delay on some of these things, since there always seems to be… But I was lucky to have a small and lightweight team that got things done quickly, compared to a larger company that might move more slowly on getting approval for a new hire. The first day probably won’t be full of excitement, but you’ll likely learn some basic details about the company and your place in it.

First day checklist:

- I know my direct supervisor and who else to turn to for help.
- I have access to whatever I need to perform my job (at least for the next day).
- I understand my process for starting, working on, and completing a task (often, this could simply be moving a JIRA ticket from the to-do section to done).
- I am as prepared as I can be to start the next day of work.

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/ducklings.jpg" style="display: block; max-width: 100%;" alt="duckling stage">
</div>

## First Week

Your first week will be a great opportunity to reach out and connect with a few of your teammates. If there are any extracurricular activities, like happy hours or company meetups, make sure to go! If there’s a teammate around your level who’s been there a little longer than you, reach out and ask what they would recommend you focus on to succeed (after all, they’ve most recently been in your position with this team). Your first week is also a great time to get a feel for what level of communication your manager is expecting. Make sure to give updates on the tasks you’re completing, and if they’re still reaching out about your tasks, it may be a sign that you should be communicating a bit more frequently.

Whatever progress is made at this point, typically you’re still catching on to company-specific conventions and processes. Try to forgive yourself for any little mistakes that are bound to happen. During your first week, it’s okay to make mistakes, as long as you’re learning from them. Also remember that, as a new part of the team, your work speed is important but not the most important variable of your job performance. I had conversations with my supervisor about how accuracy, independence, and then speed were important, and typically in that order. So don’t sacrifice one higher priority item for another, and always be aware of where you are putting your energy.

First week checklist:

- I’ve tuned or optimized my dev environment for my position. Reach out to coworkers for tips on this one!
- I’ve gathered company resources (such as handbooks, PR guides, etc.) in case I have questions.
- I know who I can pair with on any problems I’m facing (you’d be surprised what experienced developers can teach you within the span of 15 minutes).
- I’ve reached out to coworkers for advice they wish they had when they first started here (and why not add some of them on LinkedIn?).
- I am periodically checking other employee’s work (i.e. pull requests) to see what coding patterns they use and what could be considered good or bad code.

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/geese.jpg" style="display: block; max-width: 100%;" alt="geese stage">
</div>

## First Month

Around the close of my first month, I started to feel like a strong part of the team, but don’t be discouraged if it takes a little longer. At this point, you’ll probably be fully onboarded and set up for success. And really, the best thing about the first month is that it’s when you start to see growth. You’ve learned company processes, and now dividends are paying off for having a growth mindset and learning from setbacks.

Even though you seem to be establishing yourself within the team, don’t forget to focus on basics such as testing the functionality of your work and communicating effectively with your teammates. During my first month, I started to focus more on speed of development rather than accuracy and ultimately paid for it with pull request rejections. I then had to dig through non-working code to fix the issues, which can be a difficult process, especially compared to creating something correctly the first time.

First month checklist:

- I’m starting to feel confident that I’m a valuable part of the team.
- I’m asking for feedback on work when I’m not getting a clear understanding of what’s going on with my code.
- I’ve started picking up smaller tickets of my own accord (as long as they’re within your scope of work).
- I’m starting to feel comfortable in areas of the codebase where I previously may have felt confused or lost on what was going on.
- I’m still welcoming code reviews and working on not repeating mistakes that have been commented on previously. (Your managers will notice this!)

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
   <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/eagle.jpg" style="display: block; max-width: 100%;" alt="eagle stage">
</div>

## Onward and Upward

By now, you will certainly know if you’re excelling or still need to make minor adjustments. Take the time to revel in the fact that you’re doing exactly what you want to do and getting compensated to do it! It’s a long road to get where you are, and it shouldn’t be taken lightly. Continuing to grow and develop your skill set will be important moving forward, but if you’re providing value by this point, you’re on a good path.

Remember to focus on the things you can control and that no hire is perfect. If you follow some of the core principles of this guide, you’ll have plenty of resources to work with on your journey, and your journey certainly doesn’t end here. Everyone on a team was the new hire at some point, and as time goes on, you’ll probably laugh at the nervous thoughts you had leading up to your first few days. Just know that no one here wants you to fail, and your coworkers want to enjoy working with you. Keep improving, don’t listen to thoughts that make you feel like you don’t belong, and you will certainly be just fine.


Reinforced Learning