
_This article was originally posted on the [Just Eat Takeaway tech blog](https://medium.com/justeattakeaway-tech/the-amateur-is-not-who-questions-it-is-who-is-afraid-to-ask-927dc8e7e9e1)._

Introduction
============

Picture this: you’re coding along on a task and suddenly you’re stuck. You go through all the strategies and tools you can think of to find a solution, but can’t seem to figure out the issue. You might feel frustrated, perhaps starting to look for distractions to procrastinate on. You’ve reached a crossroads. Should you continue to trudge on or ask for help? You worry that the solution may be straightforward and that you might look foolish asking for help.

Another scenario: you’re in a tough planning session with your team where you’re trying to align the company’s goals with your team’s capacity. These discussions require foresight and critical thinking. Many members on your team are more experienced than you and are not shy to bring up challenging topics. You’re worried that you don’t measure up to your peers. Slowly, you find yourself fading into the background as you wonder whether you have anything valuable to say at all.

We programmers want to feel respected for our ability to solve problems and think of innovative solutions. We don’t want to be perceived as anything less than capable. As a result, we may avoid asking questions or sharing our opinions as long as possible. We worry that crossing this line will expose us as a fraud — a clear indicator of imposter syndrome.

I want to focus on this perspective — that of the developer that feels so self-conscious that they _can’t_ ask for help for fear of some level of embarrassment. This will likely affect your level of participation in discussions within your team. What I want to point out is that falling into the habit of retreating inward rather than contributing will not only inhibit your progress on a task or initiative, but it will also hurt your career in the long run.

The first step to overcoming a problem is being aware that the problem exists. In this article, we will examine these reticent behaviors and how we can overcome them.

Some background
===============

If you’ve read my previous articles, you’ll know that I’ve been part of a big team at Just Eat Takeaway that has been rebuilding the main consumer facing web application. We’ve been working on it for 2 years now and we just went live in the Netherlands, the 11th country we’ve rolled out in. It’s been a blast being a part of this project and I’ve learned and observed many things along the way.

One of these observations is the evolution of our technical discussions and how my peers and I have grown and became more vocal in the process. While I may have held back in the beginning as I was getting accustomed to working with my new colleagues, now I’m unabashed at getting involved in most discussions.

My personal development process was not always smooth, mind you. I’ve struggled with confidence issues and imposter syndrome, and I too had to look deep into my psyche to figure out how I can ultimately improve and overcome in areas where I lack.

So now I’m sharing my experience regarding those traits which I’ve noticed in myself and others as I learned what it means to be a good communicator and technical professional in a big team.

Listen critically. Be inquisitive.
==================================

Many people, including myself, have a proclivity towards shyness. I can recall being in some technical discussions where, since I was not a domain expert in the matter at hand, I found my thoughts floating away from the conversation and towards what I would have for lunch or literally anything else. You could call this boredom or lack of focus, but I think these traits are symptoms of something else, rather than it actually being a boring meeting.

A possible cause for some developers is a fear of being vulnerable, of putting yourself out there, of exposing yourself as an imposter. We worry that most of the people in the meeting will roll their eyes at our questions, that they will think “Wow, are they really asking something _that_ basic?”

The truth is that these are our irrational thoughts getting a hold of our better judgement. The only way we can learn more about the topic at hand is by listening critically to what is being discussed, asking strategic questions to gain further insight, addressing any misconceptions, and clearing up the lack of knowledge.

If you are actively engaged in the topic, you’ll feel more confident about asking questions or making suggestions. If you are wondering about something, it is likely others are too. So don’t be afraid to ask your questions. Many times, a question you ask will prompt the whole team to rightfully reexamine an aspect of the issue at hand. You know you asked a great question when someone says “Wow, I didn’t even consider that!”

Two caveats come to mind here. First, don’t make up for lack of listening by asking more questions. If a fact was already mentioned, it’s on you if you didn’t hear it and ask the exact question later. That’s why this section’s title includes “listen critically”. Secondly, don’t ask questions simply to have your voice heard. You should be conscientious about contributing and speaking up regularly, but do so because you have meaningful things to say, rather than to assert your presence. Everyone can have something meaningful to say if they are part of the conversation.

Share your thoughts
===================

Not only should you be unafraid to ask questions, but you should also be open to sharing your thoughts, opinions, and insights.

In many instances, your ears will perk up as you hear someone say “I think this is this way because of X, but I’m not sure.” You realize that you came across this information while working on a previous task. A more fearful person might assume that the other person has already considered this information and that they have way more knowledge than you do and are well aware of what you are thinking. But this is often not true and you shouldn’t assume someone else has this knowledge. Oftentimes, this information will be valuable input to the discussion.

Examples of how you can add great value to conversations are:

*   Sensing that one or more team members might be new and not have been properly introduced to the topic. You should pause the discussion to give them a one minute synopsis if it’s reasonable to do so.
*   You read or heard a piece of news that might be relevant to the discussion. The operative word here is _might_, as sometimes that piece of information is not relevant. And there’s no harm in making sure if this news is pertinent or not. Better to be sure than to hold back potentially useful information.

Don’t worry about looking like an amateur
=========================================

Fear of appearing foolish or out of the loop is often a byproduct of overthinking. It is crucial that developers overcome this anxiety as a technical professional. So many individuals are held back because they worry about what others will think of them. So they fail to become engaged in important topics and they let others take over. They end up missing out on opportunities that will help them grow professionally.

Being involved and unafraid to ask questions can inspire other team members to also become more engaged. The best way to inspire others is to lead by example. Perhaps you can recognize people in your team that actively do this, whereas others might still be learning.

Part of this mindset involves encouraging others to do the same. This helps create a safe space for your team to discuss and ask questions. Psychological safety is vital to having healthy and balanced team dynamics.

Internalizing these behaviors will make you a more experienced and agile professional. Your peers will notice your contributions and compliment you on them. You’ll be recognized for your critical thinking and shrewd observations. When a project comes around that needs a shrewd and tactful technical lead, your name will be more likely to be considered.

Getting in the habit of not worrying about looking naive will pay dividends outside of work and development. It will help you be a better family member and friend. It will help you think outside the box and look at facts from different angles. It will help you be a better learner and a better teacher. And it will make you happier.

Conclusion
==========

In order to help your team collectively wrap your heads around a topic, it’s important to ask questions and share opinions. Doing so builds confidence, critical thinking and critical listening skills, and makes you a better, more involved team member.

But overcoming social anxiety and stage fright are not trivial endeavors. Surmounting them requires introspection, mental fortitude, and courage. It requires patience with yourself and others.

My hope is that I will have inspired some of you to be bolder in your day to day discussions. Don’t always settle for your comfort zone, be involved and engaged in the foreground of the current topics in your team. Inspire your peers to step up and be involved through leading by example.

_Got feedback? Suggestions? Just want to say hi? Reach out to me on_ [_LinkedIn_](https://www.linkedin.com/in/mattfewer/) _or_ [_Twitter_](https://twitter.com/mattyfew)_!_

—

Just Eat Takeaway.com is hiring. [Apply today](https://bit.ly/TechBlogFooter)!


Being unafraid of asking questions and sharing opinions will help drive your team and your career forward.

The amateur is not who questions, it is who is afraid to ask


_This article was originally posted on the [Just Eat Takeaway tech blog](https://medium.com/justeattakeaway-tech/the-two-programmer-mindsets-adapter-architect-eb866593f3ba)._

---

Introduction
============

When a developer approaches a problem, they usually have a clear objective. Fix this bug, create that component, refactor this implementation. We are very goal oriented by nature. We have an objective that we need to get to, and we have to try all the techniques we’ve learned in order to hit that mark. But something that I feel is less discussed is the mindset of a developer: the _way_ we think, rather than _what_ we think, in order to solve a coding problem.

I want to share some thoughts on two specific mindsets that I realized I have been oscillating between for most of my career. But here’s the funny part…I rarely noticed when I was switching between them. Looking back on it, had I realized this paradigm, I might have been able to save myself hours of thinking about the perfect solutions to problems.

To give you an idea of the different stages of software development, I will give a bit of backstory to the project I’ve been working on. Afterwards, we will examine the two programmer mindsets more closely. Finally, I will present some tips on how to utilize the two approaches and how to be more mindful in the process.

My recent journey
=================

Right now, my team is at an interesting point in our long journey. Since June 2019, we’ve been migrating the Takeaway.com food ordering web application to a modern stack of Next.js, React, and Redux Saga. Over the past year, our team has grown to the point where it has become beneficial to split into smaller teams with a more specialized set of responsibilities.

We first started by building the menu & checkout pages of the website. These included the header elements, including location search and account login, and also the menu, cart, and the order submission mechanism.

Over the next 1.5 years, I moved from the team responsible for the menu & checkout experience to the restaurant list page where the user picks which establishment they will order from. Our main challenge for this page was implementing the various filters and sorting mechanisms. After finishing the restaurant list page, I pivoted to the team that handles the development of the common components of the entire website (header, footer, account login, etc).

Each team was responsible for building pages from the ground up. During this period I was mostly in what I started calling the _architect_ mindset.

Once the app started reaching completion, we weren’t building as many new features and mechanisms, and the conventions were mostly stabilized. Instead, we were following what was already in place. We deliberated and agreed to follow the coding conventions that we had established together. You can think of it as that we were building _on top of_ what was already there. This is the other mindset, what I call the _adapter_ mindset.

Two Mindsets
============

After a long time deliberating, I feel the best labels for these two mindsets is the architect and the adapter. Neither mindset is better than the other. The two work together as yin and yang. Both mindsets are utilized by developers of all experience levels. The trick is to be mindful of when it is best to be in one mindset over the other.

Let’s get into it.

Way of the Architect
--------------------

When building an application from scratch, we may assume the following:

*   If a new feature is to be implemented, there is no existing code that you can reuse. You will have to write it yourself.
*   Architectural decisions will carry a lot of weight. You will introduce new conventions.
*   You have some flexibility to introduce packages, plugins, or software that the infrastructure of your app will depend on.

In the architect mindset, you’re not going to be looking into your app for a previous implementation because there won’t be one. Being in the architect mindset means knowing that the path in front of you means exploring new ideas and designing a solution that currently doesn’t exist.

This is when we start whipping out the dry erase markers and get to the whiteboard. You are weighing the decisions of one possible implementation with another. We are thinking about the future of the software — taking one approach now can be referenced until one day it’s prevalent everywhere in your application and increasingly difficult to replace.

Way of the Adapter
------------------

The adapter mindset comes into play when you are working on a more mature application. Code conventions are in place, documentation has been written and rewritten, and you share a certain quality standard among the team members.

When we shift from needing to build something new to extending what is already there, we enter the adapter mindset. This allows us to take keep conventions for certain patterns in mind. They can be as small as preferring `Boolean(foo)` over `!!foo` or how naming our redux action creators in the past tense like `orderSubmitted`, `preferenceSaved`, etc).

In this mindset, we are more focused on using what is already there than building out something completely new or taking a new approach. We are following patterns that have been laid out by previous developers.

This is all with the healthy assumption that you and your team thought strategically about how to build your app. They have made good architectural decisions to allow your software to extend and scale. Part of following the adapter pattern includes determining whether an existing implementation should be reused or if a better and more reusable solution is needed.

Imagine joining a big project that has been active for 2+ years. As the app is being built, the team is adding models, schemas, contracts, constants, utilities, selectors, etc. to implement functionalities. These various functions will be depended upon and utilized throughout the application. As an incoming developer, you may assume that you should follow the conventions that have been laid out for you. This places you in the adapter mindset.

Is one mindset better than the other?
=====================================

You might be quick to think that we want to take the architect mindset most of the time, but I have found that this is not the case. In order to efficiently build a piece of software, a developer must drift back and forth between the two mindsets depending on the task at hand.

Placing a new developer in the architect mindset can be an effective method to find better ways of doing something, whether that be in the development process or in the code itself. On the flip side, a senior developer tasked with working with the existing codebase can also help recognize trends in the way the app is being built.

Developers must utilize both approaches in their day-to-day in order to be efficient and effective.

Switching between the two mindsets
==================================

As we previously deduced, one approach is not better than the other. In fact, as software developers we need a proper handle on both approaches. Sure, a new developer will probably be in the adapter mindset for much of the time as they learn a codebase and how to extend what is already there. Senior developers may greatly benefit from mastering this mindset. A developer that fails to recognize they can reuse a previous implementation is going to end up doing double the work — first by needlessly writing their own implementation and again when they must remove what they wrote when a colleague points out that this logic already exists in the app.

Let’s say that you’ve taken up the task of restoring user preferences from cookies or local storage after refreshing the page. Let’s assume that you have little knowledge about this topic and that the application is decently matured. A smart developer will first research which mechanisms already exist and can be reused. You ask a few colleagues who might have knowledge on the topic and then you look into the code and test the chain of events for the particular flow. These are steps that we take while we are in the adapter mindset.

Then, let’s assume another scenario where you you need to request certain user data from a separate API. You notice that there is no GET request made to this API which also requires authentication, neither of which have been implemented yet. Now you must consider how to extend the existing logic or whether you must implement these mechanisms from scratch. This is the moment where we switch to the architect mindset. We must start thinking about the architectural steps of creating something new, rather than simply use and enhance what is already there.

Some tips
=========

Now that we understand the two mindsets and relationship between them, I have some tips on how to best put our knowledge to use.

Be mindful of the way you are thinking when working on a task
-------------------------------------------------------------

Quite often we find ourselves so focused on finding a solution that we don’t stop to consider _how_ we are approaching a problem. It takes practice to zoom out for a moment and think “_Am I going about this the right way? Have I checked in the codebase for a similar implementation that can be reused? Or am I just coding away on autopilot?_” Asking yourself this type of questions will help you reflect on your own approach - something I encourage everyone to do, not just developers.

If you find you made a mistake because you weren’t in the right mindset, don’t sweat it
---------------------------------------------------------------------------------------

My inspiration for this article came from having been stuck in the adapter mindset for a day or two myself. I kept looking for an existing way to solve my problem. I kept trying to look at previous implementations from different perspectives, but I couldn’t get to a comfortable solution. I was starting to agonize over how much time I was taking, how I couldn’t get the app to behave the way I wanted; I started judging the amount of progress I had made.

Then a lightbulb 💡 went on in my head. I was trying to extend what currently existed in the codebase. Only after many instances of trial and error did I realize that I was approaching the problem from the wrong mindset. I needed to approach the problem from the architect mindset. I had done my research and testing, and determined that the solution did not exist in the codebase. I would have to build it myself.

This late realization happens more often than you would think. Don’t beat yourself up if it took you a bit of time to make the connection like I did. This is all part of growing as a developer. The important thing is that you note these moments in your career and learn from them.

Practice mindfulness daily
--------------------------

In order to program more mindfully, we must practice mindfulness when we are not coding. For thousands of years, our Buddhist ancestors touted the benefits of meditation to our mind and body.

While your development server is spinning up or when you are waiting for a webpage to load, close your eyes for a moment, concentrate on your breath, and be present for a moment. Take breaks when you feel tired. Go for a walk or exercise when you are feeling stiff. Listen to your body. Doing so will give you the energy and mental clarity to tackle coding problems with a fresh and focused mind.

Reflect on your process
-----------------------

When I first started working at JET, a colleague shared with me his daily and weekly approach for getting things done. He said that he has a “personal stand up” every morning where he examines his list of ToDos, and decides on priorities. At the end of the week, he sets aside a few hours to reflect on the previous week, answering questions like:

*   What went well? What didn’t go so well?
*   Which activities are giving you energy and which are taking energy away from you?
*   Are you maintaining good habits? Have you developed any bad ones? How can you fix them?
*   Did you make any realizations during the week that you want to focus on for the approaching week?

Asking these types of questions and actively reflecting on your own processes is a game changer as far as being mindful of how you work and go about your day instead of being on autopilot, checking off ToDos without much thought into why you are doing it, or if there is a better way.

I appreciate how these concepts are reflected in Scrum. As a practitioner of scrum and agile, you will participate in ceremonies like Retrospective, where the team will reflect on the previous sprint and ask similar questions to the ones stated above. Dedicating time to reflect on how you felt about your previous day/week/sprint is an ingenious tactic to take an honest look at how you or your team work.

Conclusion
==========

Sometimes it feels as if you are expected to know all the answers about your codebase. We fall into this thinking pattern where we need to work as fast as possible, comparing ourselves to our colleagues, and forgetting to take time to reflect on what we are actually doing. Working this way will build stress and can lead to burnout.

That’s why it’s important to _think about how you think_. When you are planning how to tackle a coding task, ask yourself “_Which mindset do I need to be in right now? Which approach will most likely lead me to a high quality solution?_”

Software development is all about trial and error. It’s always cognitively demanding. We need take care of our mind and body if we want to be effective at work and in our daily lives. Taking time to step back and reflect on how — rather than what — you think will lead you to some enlightening realizations about your own process.

_Got feedback? Suggestions? Just want to say hi? Reach out to me on_ [_LinkedIn_](https://www.linkedin.com/in/mattfewer/) _or_ [_Twitter_](https://twitter.com/mattyfew)_!_


Exploring different mindsets that developers must utilize to be mindful, efficient, and productive.

The Two Programmer Mindsets: Adapter & Architect


_This article was originally posted on the [Just Eat Takeaway tech blog](https://medium.com/justeattakeaway-tech/getting-started-with-redux-saga-54af359e84ff)._

---

The front end team at Takeaway.com has been working hard to migrate our main web application to a modern JavaScript stack. We are building the new front end application with Next.js, React, and [Redux Saga](https://redux-saga.js.org/). When we started, my experience was mostly with [Redux Thunk](https://github.com/reduxjs/redux-thunk) and [Redux Promise](https://github.com/redux-utilities/redux-promise). Redux Saga is quite a different beast, so it took some time for me to understand the underlying context, the general approach, how generator functions fit into the flow, and the pros and cons of using the library.

While on my quest to learn as much as I could about Redux Saga, I was disappointed by the lack of educational resources available. So I decided that since I have some free time due to the whole COVID-19 situation, I can create a guide for getting started with Redux Saga.

For this article, it would be helpful to understand the basic concepts of Redux, such as reducers and actions, but it is not required.

Before we jump into Redux Saga code, let’s go over some fundamental concepts first.

What is a Saga?
===============

I don’t know about you, but I was not aware of the broader programming concept of a Saga before diving into the Redux library. I will describe this concept, as it is the design pattern which Redux Saga is based on.

In the microservices world, a saga is meant to aid in implementing a transaction that spans multiple services or business domains. The saga pattern is designed as a way to handle side effects within an application. The Redux Saga homepage describes the framework as:

> A library that aims to make application side effects (i. e. asynchronous things like data fetching and impure things like accessing the browser cache) easier to manage, more efficient to execute, easy to test, and better at handling failures.

As a JavaScript developer who’s spent a fair amount of time sifting through callback-hell, that sure sounds good to me!

[This talk by Caitie McCaffrey](https://www.youtube.com/watch?v=xDuwrtwYHu8) goes into great detail about the Saga pattern.

As an example, let’s take the event of a user adding an item to their basket. Within our Redux state, we must access:

*   **the menu context** to fetch the menu item info.
*   **the restaurant context** to determine the price of the item, which can differ between delivery and pickup, special offers, etc.
*   **the basket context** to add the item and augment the price total.
*   **error contexts** in case one is thrown (and additionally, any logging services we might want to use).

A quick word about the Generator Function
-----------------------------------------

Redux Saga uses generator functions _a lot_. I definitely use generator functions the most when I am working with this framework. We aren’t going to take a deep dive into them in this article, but I recommend reading the [MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*) if you want to learn more.

For understanding the basics of Redux Saga, we only need to know a few things about this particular kind of function. Generator functions allow us to _pause_ our functions and wait for a process to finish, which is similar to the thought process behind resolving promises.

The basic syntax of a generator function looks like this:

```
function\* myGenerator() {
     const result = yield myAsyncFunc1() yield myAsyncFunc2(result)
}
```

A generator function is declared using the asterisk `*` after the `function` keyword. The `yield` keyword tells the function to wait until that line is finished running. In this case, `myGenerator` will wait (or yield) until `myAsyncFunc1` has completed, at which time the function will move on to run `myAsyncFunc2`, passing in the returned result from the first function.

There’s a lot more to generator functions than we’ve discussed, but this is enough to get you through this article and the basics for Redux Saga.

Our Example
===========

For our example, we will consider the foundations for building a food ordering application. There are certain business domains within this type of app that we need to take into account. We will refer to these differences in logic as our different _contexts._

*   **Menu**: items, categories, options or sides, sizes, prices, allergens info, etc.
*   **Checkout**: basket of selected items, total amount, tax, delivery fees, payment methods, vouchers, etc.
*   **User**: saved payment methods, saved addresses, email, phone number, etc.

**We will look at a high-level overview of how we would plan out these sagas within our app’s architecture.** Which events need to happen in each context? What will be the side effects that we want to handle in our sagas? These are the types of questions we need to ask ourselves when designing our sagas’ layout.

Are you hungry yet? Me too 😋 Ok, let’s go!

The Root Saga
=============

Similar to how reducers in Redux are organized in that we have a _root reducer_ which [combines other reducers](https://redux.js.org/recipes/structuring-reducers/splitting-reducer-logic), sagas are organized starting by the root saga.

```
function\* rootSaga() {
  yield all(\[
    menuSaga(),
    checkoutSaga(),
    userSaga()
  \])
}
```

Let’s first focus on the things that might jump out at you.

`rootSaga` is our base saga in the chain. It is the saga that gets passed to sagaMiddleware.run(rootSaga). `menuSaga`, `checkoutSaga`, and `userSaga` are what we call _slice sagas._ Each handles one section (or slice) of our saga tree.

`all()` is what `redux-saga` refers to as an _effect creator._ These are essentially functions that we use to make our sagas (along with our generator functions) work together. Each effect creator returns an object (called an _effect_) that is used by the `redux-saga` middleware. You should note the naming similarity to Redux actions and action creators.

There’s [a long list of effect creators](https://redux-saga.js.org/docs/api/) in `redux-saga`, and we will certainly cover a few. In this case, `all()` is an effect creator, which tells the saga to run all sagas passed to it concurrently and to wait for them all to complete. We pass an array of sagas that encapsulates our domain logic.

Watcher Sagas
=============

Now let’s look at the basic structure for one of our sub-sagas.

```
import { put, takeLatest } from 'redux-saga/effects'function\* fetchMenuHandler() {
  try {
    // Logic to fetch menu from API
  } catch (error) {
    yield put(logError(error))
  }
}function\* menuSaga() {
  yield takeLatest('FETCH\_MENU\_REQUESTED', fetchMenuHandler)
}
```

Here we see our menuSaga, one of our slice sagas from before. It’s listening for different action types that are dispatching to the store. For example, when we want to fetch the menu from our API, somewhere in our application, an action will be dispatched with the type `FETCH_MENU_REQUESTED`. menuSaga is watching for that actionType using `takeLatest`, and when it sees that action type, it will run a handler function — `fetchMenuHandler`. For this reason, these types of sagas are referred to as _watcher sagas_. In summary, watcher sagas listen for actions and trigger _handler sagas_.

We wrap the body of our handler functions with try/catch blocks so that we can handle any errors that might occur during our asynchronous processes. Here we dispatch a separate action using `put()` to notify our store of any errors. `put()` is basically the `redux-saga` equivalent of the `dispatch` method from Redux.

You’ll probably add separate error handling mechanisms in your own apps.

```
const logError = error => ({
  type: 'LOG\_ERROR',
  payload: { error }
})
```

Let’s add some logic to `fetchMenuHandler`.

```
function\* fetchMenuHandler() {
  try {
    const menu = yield call(myApi.fetchMenu) yield put({ type: 'MENU\_FETCH\_SUCCEEDED', payload: { menu } ))
  } catch (error) {
    yield put(logError(error))
  }
}
```

We are going to use our HTTP client to make a request to our menu data API. Because we need to call a separate asynchronous function (not an action), we use `call()`. If we needed to pass any arguments, we would pass them as subsequent arguments to `call()` — i.e. `call(myApi.fetchMenu, authToken)`. Our generator function `fetchMenuHandler` uses yield to pause itself while it waits for `myApi.fetchMenu` to get a response. Afterwards, we dispatch another action with `put()` to render our menu for the user.

OK, let’s put these concepts together and make another sub-saga — `checkoutSaga`.

```
import { put, select, takeLatest } from 'redux-saga/effects'function\* itemAddedToBasketHandler(action) {
  try {
    const { item } = action.payload const onSaleItems = yield select(onSaleItemsSelector)
    const totalPrice = yield select(totalPriceSelector) if (onSaleItems.includes(item)) {
      yield put({ type: 'SALE\_REACHED' })
    } if ((totalPrice + item.price) >= minimumOrderValue) {
      yield put({ type: 'MINIMUM\_ORDER\_VALUE\_REACHED' })
    }
  } catch (error) {
    yield put(logError(error))
  }
}function\* checkoutSaga() {
  yield takeLatest('ITEM\_ADDED\_TO\_BASKET', itemAddedToBasketHandler)
}
```

When an item is added to the basket, you can imagine that several checks and verifications need to be made. Here we are checking if the user has become eligible for any sales from adding an item or if the user has reached the minimum order value needed to place an order. Remember, Redux Saga is a tool for us to handle side effects. It shouldn’t necessarily be used to house the logic which actually adds an item to the basket. We would use a reducer for that, because this is what the much simpler reducer pattern is perfectly fitted to do.

![](https://miro.medium.com/max/2000/1*xTM3hSpOfJ_LwAS_DBCCeA.png)High level visual of the saga flow

We are making use of a new effect here — `select()`. Select is passed a _selector_ and will retrieve that piece of the Redux store, right from inside our saga! Note that we can retrieve any part of the store from within our sagas, which is super useful when you depend on multiple contexts within one saga.

What’s a selector? A selector is a common design pattern utilized in Redux where we create a function which is passed the state and _simply returns a small piece of that state._ For example:

```
const onSaleItemsSelector = state => state.onSaleItemsconst basketSelector = state => state.basket
const totalPriceSelector = state => basketSelector(state).totalPrice
```

Selectors serve as a reliable and consistent way to reach in and grab a piece of our global state.

Conclusion
==========

With not much code, we managed to create a structure for handling the events of our food ordering app. When we want to introduce the next domain of our application, we would create a new watcher saga and pass it to the root saga. Then we create handlers to listen for actions and perform side effects.

Scaling this setup is easy and logical, since we don’t have to create complex mental models and spaghetti code in order to introduce new (side) effects into our Redux flows.

Redux Saga is an excellent framework for managing the various changes and side effects that will occur in our applications. It offers very useful helper methods, called _effects,_ which allow  us to dispatch actions, retrieve pieces of the state, and much more.

In future articles, we will build a demo application and dive into more advanced concepts. I hope this served as a good primer, and that you now have a solid foundation to get started with Redux Saga.

_Got feedback? Suggestions? Just want to say hi? Reach out to me on_ [_LinkedIn_](https://www.linkedin.com/in/mattfewer/) _or_ [_Twitter_](https://twitter.com/mattyfew)_!_


An introduction to the popular JavaScript framework for handling side effects.

Articles. Musings. Ideas.

Featured Articles

The Two Programmer Mindsets: Adapter & Architect

Getting Started with Redux Saga

All Articles