Forem: Manvendra5

MVC: Model, View, Controller

Manvendra5 — Sun, 06 Oct 2024 09:36:42 +0000

Background

MVC is short for Model, View, and Controller. MVC is a popular way of organizing your code. The big idea behind MVC is that each section of your code has a purpose, and those purposes are different. Some of your code holds the data of your app, some of your code makes your app look nice, and some of your code controls how your app functions.

MVC is a way to organize your code’s core functions into their own, neatly organized boxes. This makes thinking about your app, revisiting your app, and sharing your app with others much easier and cleaner.

The parts of MVC

Model: Model code typically reflects real-world things. This code can hold raw data, or it will define the essential components of your app. For instance, if you were building a To-do app, the model code would define what a “task” is and what a “list” is – since those are the main components of a todo app. View: View code is made up of all the functions that directly interact with the user. This is the code that makes your app look nice, and otherwise defines how your user sees and interacts with it. Controller: Controller code acts as a liaison between the Model and the View, receiving user input and deciding what to do with it. It’s the brains of the application, and ties together the model and the view.

An analogy

MVC is a way to think about how an web application works.

It’s kind of like how you make Thanksgiving dinner. You have a fridge full of food, which is like the Model. The fridge (Model) contains the raw materials we will use to make dinner.

You also probably have a recipe or two. A recipe (assuming you follow it exactly) is like the Controller of Thanksgiving dinner. Recipes dictate which stuff in the fridge you’ll take out, how you’ll put it together, and how long you need to cook it.

Then, you have table-settings, silverware, etc., which are what your hungry friends and family use to eat dinner. Table-top items are like the View. They let your guests interact with your Model and Controller’s creation.

MVC in the real-world

MVC is helpful when planning your app, because it gives you an outline of how your ideas should be organized into actual code.

For instance, let’s imagine you’re creating a To-do list app. This app will let users create tasks and organize them into lists.

The **Model **in a todo app might define what a “task” is and that a “list” is a collection of tasks.

The **View **code will define what the todos and lists looks like, visually. The tasks could have large font, or be a certain color.

Finally, the Controller **could define how a user adds a task or marks another as complete. The Controller connects the View’s add button to the Model, so that when you click “add task,” the Model adds a new task.**

Wrapping up

MVC is a framework for thinking about programming, and for organizing your program’s files. To signify the idea that your code should be organized by its function, developers will create folders for each part of MVC. (The idea that apps should be divided based on the function of each part of the code is sometimes referred to as separation of concerns.) If you’ve looked at Codecademy’s Ruby on Rails course, you might have noticed that there is a folder for each part of MVC within every Rails app it introduces.

MVC gives you a starting place to translate your ideas into code, and it also makes coming back to your code easier, since you will be able to identify which code does what. In addition, the organizational standard MVC promotes makes it easy for other developers to understand your code.

Thinking about how code interacts with other code is a significant part of programming, and learning to collaborate with other developers is an important skill. Taking the time to think about how your app fits into the MVC framework will level-up your skills as a developer by teaching you both. It’ll also make your apps better!

Asynchronous Python

Manvendra5 — Sun, 06 Oct 2024 09:23:39 +0000

Asynchronous programming in python has become more and more popular lately. There are many different libraries in python for doing asynchronous programming. One of these libraries is asyncio, which is a python standard library added in Python 3.4. Asyncio is part of the reason asynchronous programming is becoming more popular in Python. This article will explain what asynchronous programming is and compare some of these libraries. Let’s take a walk through history and see how asynchronous programming has evolved in python.

One at a time

Programs have an inherent attribute that each line executes in order. For example, if you have a line of code that goes to a remote server to get a resource, that means your program is doing nothing while its waiting. It is sitting waiting for the response in order to continue. In some cases this is acceptable, but in many, it is not. The standard fix for this of course is threading. A program can spin up multiple threads; each thread doing one thing at a time.

You; caught in your many threads

Together these threads allow your program do multiple things at a time. Threading of course has many caveats that come with it. Multi-threaded programs are more complicated, and typically more error prone, they include common troublesome issues: race-conditions, dead-locks, live-locks, and resource-starvation.

Context Switching

While async programming can prevent all these issues, it was actually designed for an entirely different problem: CPU context switching. When you have multiple threads running, each CPU core can still only run one thread at a time. In order to allow all threads/processes to share resources, the CPU very often context switches. To over simplify things, the CPU, at a random interval, saves all the context info of a thread and switches to another thread. The CPU is constantly switching between your threads in non-deterministic intervals. Threads are also resources, they are not free.

Asynchronous programming is essentially software/userspace threading, where the application manages the threads and context switching rather than the CPU. Basically, in an asynchronous world, context is switched only at defined switch points rather than in non-deterministic intervals.

The Incredibly Efficient Secretary

Now lets compare these concepts with a non-computer example. Imagine we had a secretary that was incredibly efficient, and didn’t waste any time at all — was always getting things done, trying to maximize every second. This secretary — let’s call him Bob — would have to multitask like crazy to achieve this. Bob has 5 tasks he’s doing at a single time: Answering phone calls, being a receptionist (directing guests), trying to book a flight, handling meeting schedules, and filing papers. Now lets imagine this is a low traffic environment, so the phone calls, visitors, and meeting requests are few and far between. Most of Bob’s time would be spent on the phone with an airline while filing papers. This is all pretty standard and easy to imagine. When a phone call comes in, Bob would put the airline on hold, answer the phone, direct the call, then return to the airline. Anytime any task came to Bob’s attention, filing papers would be put on the back-burner because it doesn’t need immediate attention. This is one person doing many tasks at the same time, context switching in appropriate places. Bob is asynchronous.

The threading version of this would look like 5 Bob’s, each one having only one task, but only one being allowed to work at any given time. There would be a device that controls which Bob can work, which understands nothing about the tasks themselves. Because the device doesn’t understand the event nature of the tasks, it would constantly switch between the 5 Bob’s even if 3 of them are sitting there doing nothing. For example, Paper-Filing-Bob gets interrupted so that Phone-Call-Bob can do some work, but Phone-Call-Bob has nothing to do, so he just goes back to sleep. There is time wasted in switching between all the Bob’s just to find out 3 of them aren’t even doing anything. About 57% (Slightly less than 3/5) of your context switching would be for nought. And while yes, CPU context switching is incredibly fast, nothing is free.

Green Threads

Green threads are a primitive level of asynchronous programming. A green thread looks and feels exactly like a normal thread, except that the threads are scheduled by application code rather than by hardware. Gevent is a well known python library for using green threads. Gevent is basically green threads + eventlet, a non-blocking I/O networking library. Gevent monkey patches common python libraries to have non-blocking I/O. Here is an example using gevents to make requests to multiple urls at once:

As you can see, the gevent API looks and feels just like threading. However under the hood, it’s using coroutine’s rather than actual threads, and running them on an event loop for scheduling. This means you get the benefits of light-weight threading without needing to understand coroutines, but you still have all the other issues that threading brings. Gevent is a good library for those who already understand threading and want lighter weight threads.

Event Loop? Coroutines? Woah, slow down, I’m lost…

Lets clear up some things about how asynchronous programming works. One way to do asynchronous programming is with an event loop. The event loop is exactly what it sounds like, there is a queue of events/jobs and a loop that just constantly pulls jobs off the queue and runs them. These jobs are called coroutines. They are a small set of instructions, including which events to put back on to the queue, if any.

Callback Style Async

While many asynchronous libraries exist in Python, the most popular ones are probably Tornado and gevent. As we have already talked about gevent, lets focus a little on how Tornado works. Tornado is an asynchronous web framework that uses the callback style to do asynchronous network I/O. A callback is a function, and it means “Once this is done, execute this function”. It’s basically a “when done” hook for your code. In other words a callback is like when you call a customer service line, and immediately leave your number and hang up, so they can call you back when they are available, rather than having to wait on hold forever.

Let’s take a look at how to do the same thing as above using tornado.

To explain the code a little, the very last line is calling a tornado method called AsyncHTTPClient.fetch which fetches a url in a non-blocking way. This method essentially executes and returns immediately allowing the program to do other things, while waiting on the network call. Because the next line is reached before the url has been hit, it is not possible to get a return object from the method. The solution to this problem is that instead of the fetch method returning an object, it calls a function with the result, or a callback. The callback in this example is handle_response.

Callback Hell

In the previous example, you will notice that the very first line is checking for an error. This is required because it is not possible to raise an exception. If an exception was raised, it would not be handled by the proper section of code, due to the event loop. When fetch is executed, it starts the http call, then puts handling the response on the event loop. By the time we notice our error, the call stack would only be the event loop and this function, with none of our code to handle the exception. So any exceptions thrown in the callback will break the event loop and the program. Therefore all errors have to be passed as objects rather than raised. This means if you forget to check for errors, your errors will be swallowed. Anyone familiar with golang will recognize this style, as the language enforces it everywhere. This is the most complained about aspect of golang.

The other problem with callbacks is that in an asynchronous world, the only way to not block things is with a callback. This can lead to a very long chain of callback after callback after callback. Since you lose access to the stack and variables, you end up shoving large objects into all your callbacks, but if your using 3rd party APIs, you can’t pass anything into the callback that’s not expected. This also becomes a problem because every callback acts like a thread, but there is no way to “gather” the tasks. Lets say for example you wanted to call three APIs, then wait till the three are done, and return the aggregated results. In the gevent world, you could do this, but with callbacks you cannot. You would have to hack around it by saving results to some global state variables, and in the callback you would have to check if it’s the last result or not.

Comparisons

Let’s compare so far. If we want to prevent I/O from blocking, we have to use either threads or async. Threads come with issues such as resource starvation, dead-locks, and race conditions. It also creates context switching overhead for the CPU. Async programming can solve the context switching error, but comes with its own problems. In python our options are green threads or callback style of async programming.

Green Threads Style

Threads are controlled at the application level, rather than hardware
Feel like threads; Good for those who understand threading
Includes all the problems of normal thread-based programming other than CPU context switching

Callback Style

Not like threaded programs at all
Threads/coroutines are invisible to the programmer
Callbacks swallow exceptions
Callbacks are not gather-able
Callback after callback gets confusing and hard to debug.

How can we improve?

Up until python 3.3 this really was the best you could do. In order to do better you need more language support. In order to do better, Python would need some way to execute a method partially, halting execution, and maintain stack objects and exceptions throughout. If you’re familiar with Python concepts, you might realize I am hinting at Generators. Generators allow a functions to return a list, one item at a time, halting execution until the next item is needed. The problem with generators is that they must be completely consumed by the function calling it. In other words, a generator can not call a generator, halting execution of both. That is however until PEP 380 added the yield from syntax that allows a generator to yield the result of another generator. While async isn’t really the intention of generators, it provides all the features needed to make async great. Generators maintain a stack and can raise exceptions. If you were to write an event loop that ran generators, you could have a great async library. And thus, the asyncio library was born. All you have to do is add a @coroutine decorator and asyncio will patch your generator into a coroutine. Here is an example of us calling the same three urls as before.

A couple things to note here:

We are not looking for errors, because errors get passed up the stack correctly.
We can return an object if we want.
We can start all coroutines, and gather them later.
No callbacks
Line 10 doesn’t execute until line 9 is completely done. (feels synchronous/familiar) Life is great! The only problem is the yield from looks way too much like a generator, and it could cause problems if it actually was a generator.

Async and Await

The asyncio library was gaining a lot of traction, so Python decided to make it a core library. With the introduction of the core library, they also added the keywords async and await in Python 3.5. The keywords are designed to make it more clear your code is asynchronous; so your methods are not confused with generators. The async keyword goes before def to show that a method is asynchronous. The await keyword replaces yield from and makes it more clear that you are waiting for a coroutine to finish. Here is our example again but with the async/await keywords.

Basically what is happening here is an async method, when executed, returns a coroutine which can then be awaited.

We Have Arrived

Python finally has an excellent asynchronous framework, asyncio. Lets take a look at all the problems of threading and see if we have solved them.

CPU Context switching: asyncio is asynchronous and uses an event loop; it allows you to have application controlled context switches while waiting for I/O. No CPU switching found here!
Race Conditions: Because asyncio only runs a single coroutine at a time and switches only at points you define, your code is safe from race conditions.
Dead-Locks/Live-Locks: Since you don’t have to worry about race conditions, you don’t have to use locks at all. This makes you pretty safe from dead-locks. You could still get into a dead-lock situation if you require two coroutines to wake each other, but that is so rare you would almost have to try to make it happen.
Resource Starvation: Because coroutines are all run on a single thread, and dont require extra sockets or memory, it would be a lot harder to run out of resources. Asyncio however does have an “executor pool” which is essentially a thread pool. If you were to run too many things in an executor pool, you could still run out of resources. However, using too many executors is an anti-pattern, and not something you would probably do very often.

To be fair, while asyncio is pretty great, it does come with its own problems. First, asyncio is new to python. There are some weird edge cases that will leave you wanting for more. Second, when you go fully asynchronous, it means your entire codebase has to be asynchronous. Every. Single. Piece. This is because synchronous functions might take up too much time, thereby blocking your event loop. The libraries for asyncio are still young and maturing, so it is sometimes hard to find an asynchronous version for part of your stack.

That’s all Folks

Here lies the journey of asynchronous python. There are several options for you to do asynchronous programming in python. You can use green threads, callbacks, or true coroutines. While the options are plentiful, the best one of them all is asyncio. If you are able to use Python 3.5, you really should be using the one built into the python core. I encourage you to try out asyncio instead of threading for your next project.

Ways to Manage the Configuration in Python

Manvendra5 — Sun, 06 Oct 2024 09:17:57 +0000

When develop the server applications, you could encounter a problem for managing the configuration. Of course, This issue can be encountered in every place where configuration management is needed as well as server applications.

If you are beginner or have no experience with configuration management, it could be little a bit hard to do. Especially, If you have secret values like Database Information, AWS Credentials, it may be very dangerous to manage the configuration on open VCS (Version Control System) such as Github, Bitbucket. In fact, in some cases, due to careless configuration management, web application could be hacked by other hackers or seized their server resources so a ton of price is billed unexpectedly. Therefore the configuration management, especially, the secret values management is a very important issue.

In my case, I developed server applications mainly and managed the configurations in different ways for each project. So, I’d like to introduce the ways I used for help you who don’t know configuration management well.

I used Python mainly when develop the server applications, so those ways I will introduce are worked in Python. Of course, these are the “ways” to manage the configuration, so you could use these ideas in other languages too. There are no any problems.

In this post, I’ll introduce 4 ways of management as follows. (But, In here, I’ll do not talk about large scale management on infrastructure or distributed system levels. I’ll post it later)

sing built-in data structure
Using external configuration file
Using environment variables
Using dynamic loading

Using built-in data structure

It is a very easy and intuitive way. As is the title, it is using the built-in data structure for managing the configuration, basically, it can be used as follow.

Then, look at a little more complicated case. For example, If you are web developer, you may need different configurations for each development, testing, production environment, so, you can do as follow.

It is easy and intuitive to use because you can import the configuration file directly from the same project and use the built-in data structure as it is. But, if you are using the VCS, your codebase will be exposed to world, so, there could be security issues if there are secret values. Therefore, you should use dummy data (non-real data) on VCS instead of real secret data for protecting you from external security attacks. And then you will replace the dummy data with real configuration values in production server by yourself, but, it would be cumbersome. There is a slightly more advanced way of using dynamic loading, which we’ll discuss later.

So, I recommend this way if you have no secret values in configuration.

Using external configuration file

This way loads the configuration values defined in external file, not the built-in data structures. It is more general way because this way will treats the configuration as just configuration, not as a part of code. Let’s see the basic examples for using the ini and json formats as configuration. (Note that configparser is for Python 3.x, in Python 2.x, you should use ConfigParser instead)

You can also use other formats such as xml, yaml. The basic approach is same, so, any formats are ok if there is a way for parsing that formats.

In this approach, the configuration will be separated from code, so if you are using Git, just able to specify the file to ignore from VCS. However, when the configuration is completely separated from VCS, your co-worker may not able to use the configuration. So, you can use a following tip for solving this problem.

Suppose the config.json has real configuration values. Then make an example configuration file with name which indicate it is an example like config.json.example. And you should manage the only config.json.example instead of config.json on VCS. This allows other developers to know the format and manipulate the configuration by themselves. Of course, they should rename that file name with config.json to use it as configuration correctly.

Using environment variables

This way does not use the files, instead system environment variables as configuration values.

The configuration values are not managed as a separate file, so there is less risk of exposure of secret values, and it is so easy to use and can be used anywhere in codebase.

But, of course, eventually, you may have to use shell script or other scripts for managing the every environment variables systematically. So, if you are familiar with system and scripting, this way is for you. However, if some environment which unable to use the environment variables like Apache, Nginx web server, you should use other ways.

Using dynamic loading

As mentioned above, this is a more advanced way than using built-in data structures one. Previous way should import the configuration .py file from specific file which need to use configuration, so, the config file must be located on import-able path. But, In this approach, the config file does not have to located on import-able path and can even be located on other repository.

The principle is so simple. Just registers and loads the path of configuration .py file dynamically. That is, see following.

Yes, It seems very similar to first way: using built-in data structures. But, the most advantage of it is that you can separate the configuration .py file from project itself. So, this way is proper when while taking the advantages of both first and second ways, and want to (or need to) separate the configuration .py file from project codebase.

In my case, I used this way for managing the configuration repository and API server repository independently. The API server just use the configuration by import that file, but the real configuration values were managed on other repository. Then, when provisioning the servers, I’ve just cloned both repositories and make the API server able to use configuration dynamically.

By doing this, you can manage the configuration while taking the advantages of first way and you can also minimize the security risk and manage the configuration easier. Also, especially, as the size of the configuration environment grows larger, it will be more easier and effective that maintain the configuration independently from project repository.

Conclusion

So far, we talked about 4 ways to manage the configuration. In fact, it depends on your applications. Of course, you can mix them and there may be better ways than these ways. And, when the system is on very large scale, it could be better to use third-party tools or services which provide the configuration management mainly.

I hope this post will helps someone who have problems about configuration management.

How to take advantage of Local Storage in your React projects

Manvendra5 — Sun, 06 Oct 2024 09:14:48 +0000

Local Storage is a Web API native to modern web browsers. It allows websites/apps to store data (simple and limited) in the browser, making that data available in future browser sessions.

Before diving into the tutorial, it may be unclear why you’d want to even use Local Storage in your React apps.

There’s plenty of reasons and use cases, more than I can imagine, but here’s a few I’ve discovered.

A simple, fake backend for your frontend React projects — It’s often nice to add the appearance of a backend/database to your frontend portfolio projects. The extra functionality will take your app to the next level, improve the user experience and impress potential employers.
Experiment with different states while developing — When working on an app, it’s often useful or necessary for the app to have a certain state to be able to work on particular styling and functionality, (e.g. styling a list of items and removing items requires items). Rather than recreating an app’s state on every refresh, Local Storage can persist that state, making development much more efficient and enjoyable.
Saving form data across sessions — what do people hate more than filling out a form? Filling out a form twice!

Getting Started

Create a new React project using create-react-app.

npx create-react-app local-storage

cd into the new directory and fire up the app. Install yarn if you haven’t already.

yarn start
Update your App.js with the code below. Here, we’re setting up a simple to-do list app. Absolutely nothing fancy, but it’ll do the trick for playing with localStorage.

After copying over this code, you should be able to add to-do items to the list and remove them.

Start saving things to localStorage

Saving the value of our newItem input to localStorage is a piece of cake.

In the updateInput() method, we’ll invoke the localStorage.setItem() method, which takes two arguments:

key: string — the name of the localStorage item
value: string — the value you want to save for the given localStorage key. Note: Even arrays and objects need to be saved as strings. More on that in a bit.

Here’s our new updateInput() method.

As you can see, it’s not much different from updating React state.

Open up the Web Developer tools in your browser of choice, find the section for Web Storage (“Application” tab in Chrome), select the current domain of localhost:3000 and watch the value for the newItem key stay in sync with your app’s input.

Now, let’s save the list of to-do items
When adding an item, we save the new, updated list to localStorage and reset the newItem input to a blank string.

No surprises here, except for the use of JSON.stringify(). This method converts a JavaScript value into a JSON string.

Because localStorage can only store strings, arrays and objects need to be passed into JSON.stringify() before being passed to setItem().

Before moving on, we’ll also want to update the list in localStorage when deleting an item.

Ok, we’re saving. But watch what happens when you refresh the page…

…the App reverts back to its initial state! We aren’t using the stored items yet, just saving them in the background. Not terribly helpful…

In order to persist the app’s state even after refreshing the page, we need to hydrate the App‘s state with the values in localStorage, with help from a couple new methods:

localStorage.getItem() — takes a storage key and returns the value saved under that key.
JSON.parse() — converts a JSON string into a JavaScript value. You need this to correctly retrieve objects and arrays that were saved as strings to localStorage.

he below method hydrates the app’s state with the values saved to localStorage. Add this new method to your App component.

It makes sense to hydrate state when the page loads, i.e. early on in the component lifecycle. So let’s invoke this function in componentDidMount().

Once you’ve added the above code to your App component, refreshing the page no longer resets the app, but keeps it in sync with localStorage!

Continuously saving is unnecessary — there’s a better way.

While our app works as-is by saving React state to localStorage every time the user makes an update, we don’t really need to save so frequently.

Why? Because React keeps track of the state of the app throughout the user’s session — that’s what it’s for! Also, with more complex components and states, it’ll be quite cumbersome and repetitive to use localStorage.setItem() wherever the state is updated.

So rather than continuously keeping localStorage in-sync with React state, let’s simply save state to localStorage whenever the user ends their session, either by leaving the app (‘unmounting’ the component) or refreshing the page.

The new sequence of events/operations will be…

The user visits the app (localhost:3000 in our case)
The App component mounts and hydrates its state with any applicable localStorage values.
React will update state throughout the user’s session. localStorage won’t change.
When the user ends their session, save whatever the state is at that time to localStorage, making it available for hydrating in the next session.

Alright, here’s a new method for saving all of state to localStorage at once. Add it to your App component.

In order to save state to localStorage when the user leaves the app, we need to invoke the saveStateToLocalStorage method in componentWillUnmount.

CAVEAT — componentWillUnmount does not fire when the user refreshes or leaves the page, so we need to utilize the window.onbeforeunload event to be able to save to localStorage.
Learn more here.

Here’s some updated code, where we add the event listener to componentDidMount as well as add what we need to componentWillUnmount.

We no longer need to setItem when updating React state, so you’ll want to remove those.

A lot has changed since the beginning of the tutorial, so here’s the App.js file at this point. Nothing in the render() method has changed.

And that’s it! You now have the tools to use Local Storage in your React projects.

React Simple Storage — an almost shameless plug

react-simple-storage_Simple component and helper functions for using localStorage with React._www.npmjs.com

I found myself at work wanting to take advantage of Local Storage in tons of different components, so I created a component, react-simple-storage, that handles everything we’ve just implemented and much more. Keep following along to see how easy it is to use in our little to-do app.

Install it > yarn add react-simple-storage
Import it into App.js
Include it in your component, like this…

That’s it! You don’t need all of the extra methods and event listeners from the tutorial, so the final App.js using react-simple-storage looks like this…

Code example

ReactJs component lifecycle methods — A deep dive

Manvendra5 — Sun, 06 Oct 2024 09:08:33 +0000

This blog post is for the React version less than 16.3.In React v16.3 there has been significant changes in component lifecycle methods. If you are using React greater than 16.3 please refer the following blog post.

Understanding React v16.4+ New Component Lifecycle Methods_A hands-on guide to React’s new component lifecycle methods; build a simple music player!_blog.bitsrc.io

React and it’s user interface

“ReactJs is a javascript library for building user interfaces” is official one liner introduction about ReactJs.

What is User Interface?

The user interacts with application by clicking, hovering, pressing a key or performing many other events on UI components. All UI components take birth in the browser and would die at some point of time. The whole interface is governed by one God, that is the user.

The user interface is a multi option playground where the user can do anything and libraries like ReactJs helps us creating that playground.

What is lifecycle methods and why it is important?

Around us everything goes through a cycle of taking birth, growing and at some point of time it will die. Consider trees, any software application, yourself, a div container or UI component in a web browser, each of these takes birth, grows by getting updates and dies.

The lifecycle methods are various methods which are invoked at different phases of the lifecycle of a component. Suppose if we are creating the YouTube app, then obviously our app will use the network to buffer the videos and it spends the battery power (let’s assume only these two).If the user switches to another application after playing the video, then being the awesome developers, we should make sure we are using the resources like network and battery in the most efficient manner. Whenever the user switches to another application, we can stop/pause the buffering of the video, which will stop using the network and battery.

This is what the lifecycle methods in ReactJs provide us, so that the developer can produce a quality application and make sure the developer can really plan what and how to do at various points of birth, growth or death of UI interfaces.

Having a great understanding about the component lifecycle would excel your ability to develop quality ReactJs user interfaces.

Four phases of a React component

The React component, like anything else in the world, goes through the following phases

Initialization
Mounting
Update
Unmounting

The following image is the visual representation of the phases and the methods of ReactJs lifecycle.

ReactJs lifecycle phases and methods
To visualize the implementation of these lifecycle hooks we will create a music player React app named Contra music player. Let’s start our discussion on these phases.

Initialization In this phase the React component prepares for the upcoming tough journey, by setting up the initial states and default props, if any.

Contra Music player app’s initializations would look like

The component is setting up the initial state in the constructor, which can be changed later by using thesetState method.

The defaultProps is defined as a property of Component to define all the default value of props, which can be overridden with new prop values.

By rendering like Contra Music player will start with volume 70% in paused state with dark theme.

By rendering like Contra Music player will start with volume 70% in paused state with light theme.

Mounting After preparing with basic needs, state and props, our React Component is ready to mount in the browser DOM. This phase gives hook methods for before and after mounting of components. The methods which gets called in this phase are

componentWillMount is executed just before the React Component is about to mount on the DOM. Hence, after this method the component will mount. All the things that you want to do before a component mounts has to be defined here.This method is executed once in a lifecycle of a component and before first render.Usage: componentWillMount is used for initializing the states or props, there is a huge debate going on to merge it with the constructor.
render mounts the component onto the browser. This is a pure method, which means it gives the same output every time the same input is provided.
componentDidMount this is the hook method which is executed after the component did mount on the dom. This method is executed once in a lifecycle of a component and after the first render.As, in this method, we can access the DOM, we should initialize JS libraries like D3 or Jquery which needs to access the DOM.Usage: In our Contra music player app, we want to draw the sound wave graphs of the full song, this is the right method to integrate with the D3 or other third party Javascript libraries.

Where should you make the API calls?
The API calls should be made in componentDidMount method always.

Update

This phase starts when the react component has taken birth on the browser and grows by receiving new updates. The component can be updated by two ways, sending new props or updating the state.

Let’s see the list of hook methods when the current state is updated by calling setState

shouldComponentUpdate tells the React that when the component receives new props or state is being updated, should React re-render or it can skip rendering? This method is a question, should the Component be Updated? Hence this method should return true or false, and accordingly the component would be re-rendered or skipped. By default, this method return true.Usage: The example is one of the cases where I would like to re-render the component only when the props status changes.

This method is generally used when rendering is a very heavy method, then you should avoid render every now and then. For example, suppose for every render, the component generates thousand prime numbers, let’s consider some app has this kind of logic, then we can control when it is required then only the component is rendered.

componentWillUpdate is executed only after the shouldComponentUpdate returns true. This method is only used to do the preparation for the upcoming render, similar to componentWillMount or constructor.There can be some use case when there needs some calculation or preparation before rendering some item, this is the place to do so.
render And then the component gets rendered.
componentDidUpdate is executed when the new updated component has been updated in the DOM. This method is used to re trigger the third party libraries used to make sure these libraries also update and reload themselves.

The list of methods that will get called when the parent sends new props are as follows:

componentWillReceiveProps gets executed when the props have changed and is not first render. Sometimes state depends on the props, hence whenever props changes the state should also be synced. This is the method where it should be done.The similar method for the state doesn’t exist before state change because the props are read only within a component and can never be dependent on the state.Usage: This is how the state can be kept synced with the new props.

The rest of the methods behave exactly same defined above, in terms of state as well.

shouldComponentUpdate
componentWillUpdate
render
componentDidUpdate

Unmounting

In this phase, the component is not needed and the component will get unmounted from the DOM. The method which is called in this phase

componentWillUnmount This method is the last method in the lifecycle. This is executed just before the component gets removed from the DOM.Usage: In this method, we do all the cleanups related to the component. For example, on logout, the user details and all the auth tokens can be cleared before unmounting the main component.

Create a website on GitHub pages

Manvendra5 — Sun, 06 Oct 2024 08:58:43 +0000

Put your work online using GitHub Pages – no command line required!

GitHub Pages, a tool provided by GitHub, lets you easily create and deploy a website online. GitHub allows you to store all the files and code for your website in a repository. You can then use GitHub Pages to generate a personal URL and share your site with friends, family, and the world!

For this tutorial, you need a GitHub account and basic HTML knowledge. You don’t need to know Git or the command line. (But if you do want to learn how to use these tools, check out our Learn Git & GitHub.

GitHub vs. GitHub Pages

In GitHub, code is stored in a repository, or repo. You can think of it as a special folder that lives online. GitHub hosts that folder so that it is accessible to you and your teammates from anywhere in the world.

In our case, our repository will contain HTML and CSS code that defines a website. But you can’t SEE the website anywhere. GitHub just displays the code like any other text. GitHub Pages essentially connects your repository to a unique URL so that, when you go to that URL – say username.github.io – in your browser, you’ll find your website displayed.

Create a Repository

Let’s get started!

Create a new repository named username.github.io, where username is your GitHub username.
You have the option here to use a template, add a description, make your repository private, and initialize some additional files. These items make it easy for other developers to learn about your repository: what it’s about, who can access it, who can use the code, etc. For simplicity, we’re going to skip those items for now. Your site will work without them.

Click “Create Repository”.

Creating Your First Page

You should be redirected to the repository page, which shows an empty repository. It’s time to add a file! On that page, click the “creating a new file” link.

Name your file index.html. Now copy and paste the following code into the file

<html>

<body>
  <h1>YOUR NAME</h1>
  <p>Welcome to my website!</p>
  <img src="https://content.codecademy.com/articles/github-pages-via-web-app/happy-ice-cream.gif" />
</body>

</html>

You can customize the text that says YOUR NAME and Welcome to my website!.

Changes to your repository are called commits. You can imagine each commit as a snapshot of your repository at different times.

Time to create our first commit! In the first textbox, name your commit “Create index.html”. Commits usually start with a verb describing changes made to the repository.

Press the “Commit new file” button.

Viewing Your Website

Your website is now accessible at https://username.github.io! (Remember to replace username with your GitHub username.)

Troubleshooting

If your site isn’t appearing after 10 minutes, try these additional steps:

Within your username.github.io repo, go to Settings and scroll down to GitHub Pages. Under Source, make sure that your repo is linked to your web page. If you see None, then select the main branch.
Within the same GitHub Pages section, go to Theme Chooser and select any theme.

Design before you build

Manvendra5 — Sun, 06 Oct 2024 08:15:27 +0000

5 Steps to leverage design practices and tools while you build websites

Step 1: Consider your users

Whatever you are setting out to build will be used by real people—a minimum of one (you) and a maximum of billions around the world! When you write the first few lines of code you should have an answer to the question - who is this website for? Is it just for you, your friend, a client, or a community of strangers? The answer will impact how you approach the design and development of the project. Just a note—if the answer is everyone, that can be ok but you’ve got your work cut out for you - that’s 10+ languages, support for disabilities, consideration of different needs across cultural norms in all 196 countries.

Exercise to get started:

Write some information on who you are making for. List out the following:

Who they are (demographics, characteristics)
Why they would use your site/app
What you want them to take away from using it

Step 2: Consider the environment

When you build a website or app it may live on a server but it will be accessed and used in a ton of different environments. Sure you may build it on a Macbook and test it in Chrome, but rest assured someone will load your site on an outdated version of Internet Explorer, mirror it to their living room flatscreen TV, or pull it up on a terrible 3G network in the woods. It’s your job to anticipate these different environments your website will be in and design it in a way that can adapt.

Exercise to get started:

Jot down some environmental considerations you’d like to include in your project—starters below:

Will your project respond to browser size (work on mobile and big screens)
What browsers do you want to ensure your site works on? To make this decision think about who you said you are making this for.

Step 3: Wireframing

Wireframes are the blueprint for what you are going to build. Much like an architect lays out the full plans and building structure before any cement is laid, you will want to plan out how your website or app will be structured before you begin coding. If you’re working with other people or a client this step is a critical communication vehicle to make sure everyone agrees on the general functionality and structure of the project before investing hour and hours building it.

Exercise to get started:

Before you start wireframing you should have an understanding of who will use the website, a list that describes the core features of your website (user stories) and any environmental considerations you’ve decided to factor in. If you did the 5 minute exercises for steps 1 and 2 they should accomplish this.

Ok ready set.. Wireframe! Websites are comprised of content arranged in different ways. Get a piece of paper and a pencil. Think about the following core elements of your site—grid, navigation, heading, footer, and main content areas like a hero image or gallery. Start sketching out different ways of laying out each page. Below are a few steps you can take.

Draw the base grid on each page. If you are using something like bootstrap this has a predefined grid you can use. If you’ve decided to build a responsive site each full page you wireframe should also have a mobile version.

Add the main content in blocked out containers. Images, text, movies, etc whatever the content is add general containers in places that match the user needs and stories you defined earlier. Add all main buttons and other UI (user interface) elements such as icons, dropdowns, input fields.

Step 4: UI & Visual Design

Before reading any of this you may have heard or thought ‘design just makes things pretty’ So far we’ve only been talking about the design behind the scenes—no pretty involved. This step is about designing the details of how people see and use your website or app. Now you’ll get to make things beautiful using CSS.

Example: Style Guide

he best way of showing you the different elements of visual design involved in building a website is to look at a few examples of open source website style guides. These encompass the core UI & Visual Design elements and usually give explanations about how and why the elements should be used. https://ux.mailchimp.com/patterns Exercise to get started: Read this great Medium article by Erik Kennedy. It’s a good overview of UI design. https://medium.com/@erikdkennedy/7-rules-for-creating-gorgeous-ui-part-1-559d4e805cda.

Then do the following:

Find inspiration and creative direction from other sites. If it’s on a site, don’t forget you can find the fonts, colors, by looking at their code! Dribble amd SiteInspire are good places to start.

Choose a typeface - if you need help, use google fonts.
Choose a color theme - if you need help, use the adobe library

When you are setting padding and margin, add more white space than you think you should.

Step 5: Testing and Iterating

As a site or app is being built it’s important to test and validate before you ship it. This can be as simple as asking a friend to use an early prototype and give feedback, or going to a coffee shop and buying strangers coffee in exchange for 10 minutes of their time while you ask them to use your site and give feedback. This step is an important tie back to all previous steps. You can ask the following questions:

Exercise to get started:

Find a few people who are willing to test your project (ideally 5) This can be as simple as taking your laptop with a local build of your website and going to a coffee shop. Read this example of coffee shop testing. Then ask people a few questions, and ask them to start using your website. You don’t need a script of questions, at it’s simplest form this activity is about you watching real people interact with your site—at a minimum as them to think out loud so you know what parts of your site are confusing. After you do this review your notes and decide what you’d like to change based on the feedback - maybe a button placement, a content area, or general navigation.

Code coverage

Manvendra5 — Sun, 06 Oct 2024 08:09:21 +0000

In this article, you will learn about code coverage and test coverage – two metrics that organizations can use to determine the extent to which an application's code has been tested – and why these metrics are useful.

What is Code Coverage?

Code coverage is the metric that measures the amount of application code that has been executed in testing, represented as a percentage. For example, if 90% of our code has been executed in our tests, then we would say that we have “90% code coverage”.

But what does it mean for code to be executed in a test? How rigorous does a test need to be in order to qualify as having executed the entirety of a program? And does 100% test coverage mean that a program is bug-free?

Code Coverage Criteria

Measuring code coverage is conducted using one or more criteria, depending on the organization’s standards for code coverage. Though this is not an exhaustive list, some key criteria to use when measuring code coverage include:

Function Coverage: Has each function been called?
Statement Coverage: Has each statement been executed?
Path Coverage: Has every edge in the control-flow graph been executed?
Condition Coverage: Has each boolean sub-expression evaluated to be both true and false?
Let’s look at an example of how these criteria can be used to determine code coverage. Here we have a very simple function that returns the sum of two arguments, if two arguments have been provided, and returns null otherwise:

function numSum(x, y) {
  if (x && y) {
    return (x + y);
  } else {
    return null;
  }
}

The most basic test of this function would include calling the function at least once, thus achieving 100% function coverage.

numSum(1, 2);  // This should return 3

By executing the function only once and with the arguments above, we will execute some, but not all, of the lines of code in the function. So, we can test our function by calling it with arguments that will return null:

numSum(1, 2);  // This should return 3
numSum(1, false);  // This should return null

With these two calls together, both paths in the if / else blocks are taken and both return statements are executed. Thus, we have 100% statement coverage and 100% path coverage.

Finally, to achieve 100% condition coverage, we need to call our function with arguments such that x and y each evaluate to true and false in the function’s if condition statement.

numSum(1, 2);  // This should return 3
numSum(1, false);  // This should return null
numSum(false, 1);  // This should return null
numSum();   // This should return null

The 100% Code Coverage Myth

And there we have it, we’ve achieved 100% coverage in each of the four criteria! So, we’re done testing, right? Well, not quite.

Having 100% code coverage does not guarantee bug-free code – it simply validates the completeness of our tests using a given set of criteria relative to other test suites with lower code coverage. We still must be vigilant about writing robust test suites that specifically address both the intended use cases, and unintended edge cases, of our application.

For example, as written, the numSum function will concatenate numeric string arguments rather than performing addition.

numSum('1', '2') // This will return '12' instead of 3

While there are other coverage criteria we can use to identify the full range of function parameters, code coverage is an insufficient metric to determine if our tests confirm the intended functionality of our program as defined by the end user’s requirements.

Instead, we should consider the code coverage criteria as a set of guidelines to help you develop intuition for testing your code while remaining determined to write robust test suites that are specific in targeting the various use cases of our programs.

Test Coverage

Another term you may hear with regards to testing is called test coverage. Test coverage differs from code coverage in that test coverage measures the percentage of the required features/specs that are tested, as opposed to the percentage of lines executed. These features/specs are typically defined in a requirements document provided by a client or product designer.

Suppose you are building a mobile-native application that needs to work on phones using the Android and iOS operating systems but is not expected to work on desktop browsers. Accordingly, to achieve high test coverage, you will be expected to write tests for your application’s performance on Android and iOS but not on browsers.

Like code coverage, test coverage cannot guarantee that our program will not have unexpected behavior. However, the pursuit of high test coverage can lead us to identify bugs and unexpected behavior earlier on in the development process.

Conclusion

Code coverage measures the percentage of lines of code that are executed in a test while test coverage measures the percentage of required features that are tested. Though these metrics cannot guarantee bug-free code, by incorporating these two metrics into your test analysis, you can increase your confidence that your test suites are robust and that your products can satisfy your end users.

How to write good tests?!

Manvendra5 — Sun, 06 Oct 2024 08:04:23 +0000

A test suite is a collection of tests that you can run against a piece of software. The goal is for these tests to catch any errors in your software before you make it available to the end user.

A good test suite is one that doesn’t take long to run, and if all the tests are passing, provides you with confidence that your software is working as expected. If a good test suite catches a bug, it will return feedback that can help you identify the source of the issue, and help you resolve it.

A bad test suite may take a long time to run and/or, if passing, won’t provide you with confidence that your software is working as expected. If a bad test suite catches a bug, it may not return helpful feedback or be a false negative, which will make it challenging to identify the source of the issue.

If you keep these characteristics in mind as you write tests, you improve the chances that your test suite will run efficiently and it provides you with confidence that your software is working as expected.

Fast
Complete
Reliable
Isolated
Maintainable
Expressive

Characteristics of an Effective Test Suite

1.Fast
As you learn more about tests in the context of full-stack web applications, you will find that some types of tests, called unit tests, are fast, while other tests, called integration tests, are slower. If your test suite contains a large collection of integration tests, and few unit tests, you may end up waiting a few minutes or even hours for your test suite to execute.

A fast test suite will provide feedback more quickly, and thus, make the development process more efficient than a slow test suite. Often, a developer who is trying to fix a bug will need to run the test suite multiple times to see if their implementation addresses the issue. If they work on the bug for two hours, and need to run the test suite five times, a test suite that takes thirty seconds to run will save 22 minutes over a test suite that takes five minutes to run — the difference can be this significant.

2.Complete
A test suite that covers 100% of your codebase will catch any errors that arise from changing or adding code application. A complete test suite provides you with confidence that your software is working as expected. This characteristic can often run in conflict with building a fast test suite — as you investigate testing further, you will learn about strategies that help you optimize your test suite for speed and completeness.

3.Reliable
A reliable test suite is one that provides consistent feedback, regardless of changes that may occur outside the scope of a given test. An unreliable test suite may have tests that fail intermittently, with no helpful feedback about changes you’ve made to your application.

If a developer is trying to address a bug in their codebase, they will need to run their test suite a few times to see if they’ve addressed the issue. What if they run the test suite two times in-a-row and don’t change their implementation, but receive different sets of failing tests? This is a sign that the developer’s test suite is unreliable. It’s like trying to hit a moving target — they can’t trust if their implementation is wrong or if their test suite is unreliable.

4.Isolated
An isolated test suite contains tests that run without impacting other tests in the suite. This may require you to cleanup persisting data after you run a test in your suite.

For example, you may want to test whether your software properly writes to a database. You don’t want any changes to the database persisting outside of this test. If a change to the database does persist, it may cause unexpected behavior in a test that reads from the database.

5.Maintainable
A maintainable test suite is easy to manipulate — you should be able to add, change, or remove tests with ease. If you don’t know how to add tests to run against new features, your test suite may become incomplete and ineffective.

The best way to keep your test suite maintainable is to be organized, follow coding best practices, and develop a consistent process that works for you and your team.

6.Expressive
The easy-to-read nature of test suites make them a great form of documentation. You should always write code that is descriptive of the features you are testing.

You should try to build a test suite that is descriptive enough for another developer to read, and be able to fully understand the purpose of the web application. Also, because your test suite is part of your software, it is more likely to stay up-to-date than a README or documentation that isn’t a functional piece of the software.

Conclusion

In this article, we covered six characteristics of a good test suite. Use these characteristics as you begin to build your own test suites, and as you evaluate the utility of strategies to approach test suite development.

Keep these top-of-mind as you begin building and evaluating your own test suites. The MC-FIRE acronym (Maintainable, Complete, Fast, Isolated, Reliable, and Expressive) may be a helpful acronym to remember these characteristics as you work!