DEV Community: Leissan

Context API (React)

Leissan — Mon, 22 May 2023 13:36:11 +0000

The Context API is a React structure that enables you to exchange unique details and assists in solving prop-drilling from all levels of your application. It is a React built-in feature, so we don’t have to worry about performance overhead and library installing issues.

The React Context API is a way for a React app to effectively produce global variables that can be passed around. This is the alternative to "prop drilling" or moving props from grandparent to child to parent, and so on. When a project grows, data passing through props becomes more complicated, making the code more vulnerable and complex. Context is also regarded as an easier, lighter approach to state management using Redux.

Here are a few benefits of Context API that make it stand out:

The Context API helps share data between components which you can’t easily share with props, for example, complex data objects.
React Context API provides a way to send data like userid, auth, and theme data through the component tree without sending any props manually at every level.
We can also share specific states with multiple components instead through props manually. In some use cases, ideal for theming, localization, authentication etc.

CONTEXT API VS USECONTEXT

Context API
The Context API is the React feature used for solving props drilling problems. In Context API, we give data access to a component tree at the start to end level instead of using props.
useContext
The useContext is the React built-in hook, used in context API to consume the context state or object.

Context provides a way to share data between components without explicitly passing props at each level. By invoking the useContext function and passing the context object as an argument, we can access the context value within the component.

To use the useContext hook, we need to follow two main steps: creating a context and consuming it in the desired components.
We can create a context using the createContext function provided by React. This function returns an object with a Provider and a Consumer.

The createContext function optionally accepts a default value that will be used when no matching Provider is found in the component tree.

Provider: The Provider component is responsible for providing the context value to all the components that are descendants of it. It accepts a value prop, which can be any JavaScript value. This value will be made available to all the components that consume the context using the useContext hook.
Consumer: The Consumer component is an optional way to consume the context value in class components or functional components where hooks are not available. It provides a render prop pattern, where the consumer component receives a function as a child. This function takes the context value as an argument and returns the JSX to render.

Here's an example of how to create a context and use its Provider and Consumer components:

While the Consumer component is still available for backward compatibility and for use in class components, the useContext hook provides a more concise and direct approach to consuming context values within functional components.
Similarly, by using the useContext hook, we can directly access the context value without the need for a separate Consumer component:

With the useContext hook, we can simplify the code and make it more readable by directly accessing the context value within the functional component.

Overall, the createContext function in React enables us to create a context object that consists of a Provider and a Consumer. The Provider is responsible for providing the context value to its descendants, while the Consumer allows components to consume the context value using a render prop pattern. However, with the useContext hook, we can consume the context value directly within functional components, making the code more concise and easier to understand.

Active Record Validations

Leissan — Sat, 01 Apr 2023 03:48:09 +0000

Why are data validations important? We perform validations in order to ensure that only valid data is saved into our database. It may seem as if data validation is a step that slows down our pace of work, however, it is an essential ingredient to our workflow rather than an additional step.

We are doing so many important things online, like open bank accounts, sign into our student portals, check our flight status, etc., all of which are powered by data. And data validations are the most effective way to ensure data quality and integrity.

As we know, Ruby on Rails is structured on the MVC architecture. The "M", also called the model layer, is responsible for managing how objects are created and stored in a database. In Rails, the model layer is run by Active Record by default, and as such, Active Record is responsible for handling the important task of data validation. Model-level validations protect our database, because they ensure that only valid data is saved there.

What are some of the types of validations we can perform with Active Record? There are some validations that come packaged with Active Record, and there are custom validations, that we can build ourselves.

Build-in Active Record Validations

First of all, it’s important to know that not all methods trigger validation!

The ones that trigger validation are:
• create
• create!
• save
• save!
• update
• update!

These ones do NOT trigger validation:
• decrement!
• decrement_counter
• increment!
• increment_counter
• insert
• insert!
• insert_all
• insert_all!
• toggle!
• touch
• touch_all
• update_all
• update_attribute
• update_column
• update_columns
• update_counters
• upsert
• upsert_all

There are numerous validation helpers we can use to validate different aspects of our data. We can use valid? to trigger our validations and to return true if no errors were found in the object, and false otherwise. Let’s run through some examples.

One of the most common situations we all have come across is to have a mandatory piece of data when we are filling out a form. For example, we want to make sure the user definitely inputs their username in some form. This is how we would make sure that they do:

Here we used a helper “presence” which – you guessed it! – ensures that a specific attribute is filled out. Easy and effective!

What is we want to go a step further and make sure that not only they filled out their username, but that it is also unique? Here comes another helper, uniqueness:

If there is anything wrong with our data, there is a list of error messages saved when .valid? returns false. We can see these error messages through using the .error.messages method. We can also use .invalid?, which is the reverse of the .valid? method. Let’s see that in action:

Errors.messages are extremely important, because they will tell us exactly what went wrong with our data. We can also check each attribute for errors separately, passing it as a key:

There are a couple of important moments here. First of all, we can see that the validation does not trigger until we try to use a method which triggers validation, in this case – save. There is no error message before we save! Secondly, we can see a specific error message related to an attribute we want to check, :username, by running u.errors[:username].

You can access a full list of validation helpers on Rails Guides.

Custom Validations

We don’t have to limit ourselves to pre-built validations (although they are very useful!). Active Record gives us several easy ways to build custom validations, the most straight forward of which is to use a custom method to perform a validation. Let’s say we are building a website for travelers, and we want to make sure their favorite destination includes Brazil:

A couple of key moments here: with custom validation, we are using the method “validate”, not “validates”, and then we are passing it a method that we define ourselves below. We also specify our custom error, should the user not follow our fave_destination rule.

Speaking of errors, ideally we want our controller to tell us if, for example, our user data was saved successfully, and if not, tell us exactly why not. How would we do it with built-in validations? Below we are updating our controller action to provide is a specific response if the user was not saved successfully:

And there we have it - we just learned the best ways to ensure our data integrity using Active Record!

Ruby Variables

Leissan — Mon, 03 Oct 2022 02:25:27 +0000

In programming, a variable is basically a container which allows us to store information, something that holds a value.

Ruby has 5 different types of variables: as you might expect, there are local and global variables, there are instance and class variables, and there are constants. The way we can tell which is which is typically by using a special character at the beginning of the variable name. Let’s review them one by one.

Local Variables

A local variable name always starts with a lowercase letter(a-z) or underscore (_). These variables are local to the code block in which they are declared; their scope ranges from class, module, def, or do to the corresponding end or from a block's opening brace to its close brace {}. A local variable is only accessible locally, within the block of its initialization. Local variables are not available outside that block.

Local variables do not have any value (even nil) before initialization, which means you will encounter an error like the one below if you try to declare one without assigning its value:

The first assignment you make to a local variable works essentially like a declaration. When you are trying to reference an initialized local variable, Ruby interprets it as a call to a method that has no arguments (and we get the error like the one above).

Global Variables

Global Variables start with a dollar sign: $:

In our code snippet above, we are declaring the global variable on top level, outside of any class. When we test this code in IRB, we can see that this variable is available (or in scope) in both classes:

As we can see the scope of the global variable is such that it can be accessed across classes, from anywhere in your program, in other words – the scope is global. When a global variable is uninitialized, it has no value by default and its use is nil.

Instance Variables

An instance variable always starts with a @ sign. It is defined within the class body and belongs to a specific instance of that class. Its value is not shared between different instances of that class but rather it is local to specific instances of an object. Instance variables are available across methods for any specified instance or object i.e. instance variables can change from object to object. There is no need to initialize the instance variables and uninitialized instance variable always contains a nil value.

In the code snipper below, we created a class Toy, which has specific attributes like name and color. These attributes become our instance variables, with @ sign in front of them. As you can see, instance variables are declared inside the class.

Here we created two new instances of our Toy class: a red ball and a yellow truck. These attributes are describing not the entire class but only that specific instance (or instances) we created.

An instance variable belongs to the object itself (each object has its own instance variable of that particular class). One instance object can alter the values of its instance variables without modifying any other instance.

Class Variables

A class variable is a variable defined in a class body that can be interacted with without an instance of such class. Class variables are shared among all instances of the class and its subclasses. This means that only one variable value exists for all objects instantiated from this class. If one object instance changes the value of the variable, that new value will essentially change for all other object instances. It may make more sense once you review the code below:

Here, we have the same instance variables we reviewed above (@name, @color), as well as a class variable @@toy_count. The reason we are using a class variable here is because we need to keep track of data beyond just the instance level. Each instance of the toy has no idea how many other instances are there; it seems like the job is better suited for our class Toy.

The key practical difference between a class and an instance variable is that class variables (@@) are shared among a class and all of its descendants (like toy_count in our example), while instance variables (@) are not shared and each class has separate instance variables just like you would expect from different objects (like red ball and yellow truck).

Constant Variables

A constant is a type of variable which always starts with a capital letter. They can only be defined outside of methods, unless you use metaprogramming.
As long as you create a constant outside of any class, at the top-level of your code, that constant will be available anywhere, including inside class methods, outside the class, and in child classes.
Constants are used for values that aren’t supposed to change, but Ruby doesn’t prevent you from changing them, which could potentially be tricky for your code. This is why you wouldn’t typically use them very often in your code.

Exchanging data between React components

Leissan — Sun, 10 Jul 2022 13:28:47 +0000

A Component is one of the core building blocks of React. A React component takes an optional input and returns a React element which is rendered on the screen. How the data is passed between the components will depend on their hierarchy, or Parent/ Child/ Sibling relationship.

1. Passing data from the Parent component to a Child Component

The most straightforward way to pass data between components is to pass it from a parent to a child, which is be done by using props. React allows you to pass props but only in one direction, parent to a child, and not the other way around. In the example I have below, we are passing a prop with a name of faveSnack that is equal to a value of a string (in our case, of course, “pizza”). Passing a prop gives us access to the information in our Child component. To access the prop in our Child component we use props.faveSnack.

We could also just use our prop faveSnack directly, through something that’s called destructuring props. This is what it would look like:

2. Passing data from a Child component to a Parent component.

Here is where things are starting to get tricky, because - as you now know – we cannot pass props from a child to a parent. What we can do however is use callback functions. When we use a callback function in a Child component it can then make changes to a Parent component.

Let’s review the steps:

In the parent component, create a callback function. This callback function will retrieve the data from the child component.
Pass the callback function to the child as a props from the parent component.
The child component calls the parent callback function using props and passes the data to the parent component.

In the example below, we are using the callback function to handle the onChange event in the child component and pass the value from the input element as an argument to the callback function passed down as a prop, which is called snackHandler here. The function handleSnackChange takes an argument – an event, and passes the current value to the snack state variable. The event handler, while it is defined in the Parent component (or owned by it), is passed to the Child component as a prop and then called in that same Child component (or invoked by it).

3. Passing data between 2 Child components, or siblings.

In order to pass data between siblings, there are several methods we can choose from:

Combination of the above two methods (callback and use of props).
Using Redux.
ContextAPI

For this post, I will focus on the first method in the spirit of establishing the communication channel between components using just React.

There is no direct way to pass the data between two (or more) children components; we need to use the Parent as a way to connect the siblings. The easiest way to think about it would mean combining the first two ways of passing data between the components that we just went over above.

First, we would need to define a callback function in a Parent component (which will own the callback function) and then send it to Child 1 as a prop. We are setting a state variable “snack” and updating its value using the callback function from Child 1, the way we did it above in the example of passing data from a Child to a Parent. The onChange event in Child1 component is being handled by the callback function handleSnackChange which is passed to Child1 as snackHandler prop from a Parent component. The value from Child1 input element is passed as an argument to the callback function handleSnackChange which in turn passes the current value to the snack state variable.

So far, the steps have been identical to the ones described in passing data from Child to Parent, since, as we established already, the parent must act as the intermediary between the siblings. Now that we passed the data from Child1 to the parent (as an argument in a callback function), we are setting it in a state in Parent component, then passing it as a prop to Child2:

To sum up, we can pass data from a Parent to a Child component using props, from a Child to a Parent using a callback function, and between the siblings using a combination of both.

Thank you for reading!

JavaScript Variables

Leissan — Fri, 15 Apr 2022 03:39:09 +0000

First of all, let's define what is a variable. Simply put, a variable is something that holds a value. It has an identifier (or a name) which can contain letters, digits, and special symbols. In order for us to "declare" a variable we can use three methods: let, var, and const.

As a general rule, if you do not want the value of your variable to change throughout the entirety of your code, declare it using const (the value will remain constant, get it?). This will ensure that it cannot be redeclared and cannot be reassigned. Let's see that in action:

const snack = "ice-cream"

Here we declared our variable (snack) and assigned a value to it (ice-cream). If we want to retrieve the value of our variable, we can simple run snack and get ice-cream in return:

What happens if we try to re-assign the value? Let's see:

Hmmmm it doesn't like that. Perhaps we can just re-declare the value?

Nope, that does not work either!

What if we would like a bit more flexibility here, and want to be able to re-assign the value of a variable? Here we would use the variable let:

Mind you, we still will not be able to re-declare the value of let, but we can re-assign it. In the same situation, const is throwing us an error.

And most flexible of all, var, can be both re-declared and re-assigned it's value:

So, to sum it up, var variables can be re-assigned value and re-declared; let variables can be re-assigned value but not re-declared; const variables can neither be re-assigned value nor re-declared.

But these are not the only differences; they also differ in scope, or essentially in their availability for use in various parts of code. Here we will cover two types of scope: global and local.

If a variable is declared outside of any function it is a global variable. Global variables can be accessed from within any function:

Variables declared inside any function are called local variables. Local variables cannot be accessed outside the function:

An important thing to note is that in JavaScript, a variable can also be used without declaring it, meaning we will not use var, let, or const to declare it. If a variable is used without declaring it, that variable automatically becomes a global variable:

We should also mention something that’s called a block scope. A block is, generally speaking, anything within curly brackets; it could be for or while loops, if statement, etc. Block scoping means declaring a variable inside those curly brackets. It is within the concept of a block scope that we can see different behaviors of our three variables.

When it comes to a var variable, it is globally scoped if we declare it outside of the function, and locally (or functionally) scoped if we declare it within the function. It is not block scoped! This means if we declare a variable using var inside a block of code, we can just as easily access it outside of that block of code, on a function level:

As we can see, we have no issue printing out the value of a variable “snack” (which was defined inside a block of code) both within the block and outside of it. That, along with the fact that we can both re-assign and re-declare it’s value, can potentially create complications and errors in our code, which is why const and let are typically preferred over var.

You see, unlike var, both const and let actually respect the block scope; if we declare a variable using these two inside a block of code, we will not be able to access it from the outside of the curly brackets, not on a function level, and not on a global level. This can open up a lot more possibilities for our code! Let’s see how const behaves in the very same situation we just saw above:

As we can see, only the console.log inside the block of code worked. We can observe the same behavior with let:

To sum up, the main differences when it comes to scope are: let and const variables are block scoped, var are NOT (only globally or functionally scoped). These differences, along with the differences in their ability to be re-declared and re-assigned, open up very different possibilities with each of these variables when we code.

Thank you for reading!