DEV Community: Oumayma JavaScript Developer

Elixir: Repeating the same function multiple times in pipe

Oumayma JavaScript Developer — Fri, 04 Nov 2022 14:44:31 +0000

Piping is a trade mark for elixir developers, it makes the code cleaner, easier to read and overall more organized.
Instead of chaining function returns like this:

foo(bar(baz(new_function(other_function()))))

Piping allow us to do this:

other_function() |> new_function() |> baz() |> bar() |> foo()

Where the data flows from up to bottom.

Sometimes on our programming journey we need to perform the same function n times while piping.

1. Performing the same function on enum items inside a pipe:

We have Enum of strings that we want to transform to uppercase.

people = ["Qui", "Quo", "Qua"]
people|> Enum.map(&String.upcase/1)

2. Piping the same function multiple times on the same variable.

For example let's say we have a struct that we want to validate the fields.
In this case we can simplify the piping using a function

def validate_lengths(changeset, fields, opts) do
  Enum.reduce(fields, changeset, &validate_length(&1, &2, opts))
end

usage:

my_struct |> validate_lengths(fields)

Make your text input look like a password input

Oumayma JavaScript Developer — Wed, 17 Aug 2022 15:49:00 +0000

Ever wondered why password inputs look like ****** ,
turns out it's because of -webkit-text-security property.
Here's how to make a simple text input look like a password input:



input.pw {
  -webkit-text-security: disc;
}

input.pw2 {
  -webkit-text-security: circle;
}

input.pw3 {
  -webkit-text-security: square;
}



<input type="text" class="pw" value="secret"/>
<input type="text" class="pw2" value="secret"/>
<input type="text" class="pw3" value="secret"/>

result :

How to use Jsonp in your project.

Oumayma JavaScript Developer — Sun, 20 Feb 2022 11:45:24 +0000

The first time I heard about JSONP was when I recieved a technical assessment for a high end company.
When I saw it, I immediately thought: what is it? why we use it? how does it work? and how do I use JSONP in my project.
So here I will share the answer to all those questions in one place!

What is JSONP?

JSONP (JSON with Padding) is a javascript object notation it´s used to load data from the server using a script tag <script> rather than XMLHttpRequest.

Why we use it?

The short answer is that it´s used to avoid Cross-Origin-Resource-Policy issues.
While corss-domain policy blocks accesssing files, it allows accessing scripts from another domain. JSONP uses this to access data through a script tag.

To achieve that, JSONP objects come wrapped in a callback function.


//JSON Example
{"Name": "Foo", "Id": 1234, "Rank": 7};

//JSONP Example - In this you can call a function
functionCall({"Name": "Foo", "Id": 1234, "Rank": 7});

How does it work?

The client (typically JavaScript) must provide a callback function to which the data is later transferred, along with any other data the client wants to send.
The data transfer is called up on the client by formulating a script call. The URL of the web service on the server is specified, supplemented by the name of the callback function. The finished "script" tag must then be injected into the DOM (Domain Object Model). This process is called "script tag injection" and triggers the data transfer.
The web service on the server side takes the data, extracts the name of the callback function and uses it to bracket the server data with an appropriate function call when it is sent back .
The browser receives the server response back in the form of a script and immediately begins executing the script. Since the script consists of a function call, the "callback" function is called and this receives the data as a parameter.

How do I use JSONP in my project?

Javascript:


async () => {
    const jsonpCallback = "<CALLBACK_FUNCTION_NAME>";
    const response = await fetchJsonp(`<API_URL>`, {
      jsonpCallback,
    });
    const data = await response.json();
    return data;
  }

Finally,

I hope you found this article helpful,

Set up a Dockerfile for your angular application with Nginx

Oumayma JavaScript Developer — Sun, 16 Jan 2022 09:34:53 +0000

Running your application in docker container is the first step towards production. We have to make sure that our app can build successfully , independently of our local environment.
Bellow you can find a basic dockerfile for your angular application that uses nginx server to render the html.

FROM node:12-alpine as build

WORKDIR /app

COPY package.json .

RUN yarn install

COPY . .

RUN apk add gettext

RUN yarn build --base-href

FROM nginx:latest

COPY --from=build /app/dist/hr-frontend /usr/share/nginx/html

EXPOSE 80

The above dockerfile will run your application on port 80.
To test it, in the root of your project run:

docker image build --tag <your image name> .
docker run -d -p 8000:80 <your image name> This command will serve your application on port 8000. The port 80 is where your application is running inside the container.
Go to localhost:8000 .

Angular Best Practices

Oumayma JavaScript Developer — Fri, 14 Jan 2022 16:10:55 +0000

Working at a large company where we have plenty of web applications with continuous releases and feature improvements taught me the value of implementing good coding practices. With such feature velocity, it is important for the team to do things the best way possible. This helps to reduce technical debt and makes scaling up much less complicated.
Bellow I put some of angular coding standards and practices to improve your angular application performance.

1. Naming Conventions

File naming:
- Names of folders and files should clearly convey their intent.
- Names should be consistent with the same pattern in which we mention the file’s feature first and then the type, dot separated.

For example consultation.component.ts or home.component.html or auth.service.ts .

Class and Method naming: It is advisable to use the upper camel case style as a suffix. For example DatepickerDirective , AuthService , onClick.
Name variables that are observables with a $ at the end. (There's a debate to use this or not, but I think it's a good way to spot observable variables easier)

2. Project Structure

Creating a folder structure is an important factor we should consider before initiating our project. Our folder structure will easily adapt to the new changes during development.

Keep the structure as flat as possible. We should not create nested structures just for the sake of structures and we should only create subfolders when we feel that the contents of a folder is hard to read at a glance. Keeping the flattest structure possible also makes imports more readable

Keep related code grouped. For example, keep the shared components in a folder, feature components in their feature folder, and so on.

Example:

3. Angular Coding Styles

Here is a set of rules we need to follow to make our project with the proper coding standard.

Per file, the code must not exceed 400 lines limit.
Per function, the code must not exceed 75 lines.
Utilize custom prefixes to prevent element name collisions with components in other apps and with native HTML elements.
If the values of the variables are intact, declare it with const.
Names of properties and methods should be in lower camel case.
Always leave one empty line between imports and modules such as third party and application imports and third-party module and custom module.
We shouldn’t name our interfaces with the starting capital I letter as we do in some programming languages.

4. Single Responsibility Principle

It is very important not to create more than one component, service, directive… inside a single file. Every file should be responsible for a single functionality. By doing this, we are keeping our files clean, readable, and maintainable.

In the same way, every module, class, or function should have responsibility for a single functionality and it should encapsulate that one part.

5. Lazy Loading

Try to lazy load the modules in an Angular application whenever possible. Lazy loading will load something only when it is used. This will reduce the size of the application load initial time and improve the application boot time by not loading the unused modules.

// app.routing.ts
{
path: 'lazy-load',
loadChildren: 'lazy-load.module#LazyLoadModule'
}

6. Typing

Declare variables or constants with proper types other than any. This will reduce unintended problems. For example use id: number; instead of id: any;
Use let rather than var.
Declare safe strings: The variable of type string has only some set of values and we can declare the list of possible values as the type. So the variable will accept only the possible values. We can avoid bugs while writing the code during compile time itself.
Use const when the variable has a constant value.

7. API Calls Best Practices

Avoid having Subscriptions Inside Subscriptions

Technically, nested subscriptions work, but it is not the most effective way. In case, you want the value to be reused in more than one observable then you can use preferable chaining options like combineLatest, withLatestFrom, etc rather than subscribing to one observable in the subscribe block of another observable.

Example:

observable1$.pipe(
    withLatestFrom(observable2$),
    first()
)
.subscribe(([res1, res2]) => {
    console.log(`${res1} & ${res2}`);
});

Isolate API Calls

It is better to isolate API calls in one place, like in a service and use the service from the component. This way we can add logic to these calls closer to the call and independently from the component logic.

Unsubscribe from Observables

When subscribing in your components to RxJS Observables, you should always unsubscribe. Otherwise, this causes unwanted memory leaks as the observable stream is open, even after destroying the component using it.

You can do this in multiple ways:

-Unsubscribe the component in the ngOnDestory event after destroying the component

-Use the async pipe to subscribe to Observables and automatically unsubscribe in templates.

Subscribe in template

Avoid subscribing to observables from components and instead subscribe to the observables from the template. Here’s why:

It makes the code simpler by eliminating the need to manually manage subscriptions since async pipes unsubscribe themselves automatically. It also reduces the risk of accidentally forgetting to unsubscribe a subscription in the component, which would cause a memory leak. (This risk can also be mitigated by using a lint rule to detect unsubscribed observables.)

Before

// template

<p>{{ textToDisplay }}</p>

// component

iAmAnObservable
    .pipe(
       map(value => value.item),
       takeUntil(this._destroyed$)
     )
    .subscribe(item => this.textToDisplay = item);

After

// template

<p>{{ textToDisplay$ | async }}</p>

// component

this.textToDisplay$ = iAmAnObservable
    .pipe(
       map(value => value.item)
     );

8. Reusable Component

Components should obey the single responsibility principle. This helps to eliminate code duplication. Components should also only deal with display logic. It is important to separate business logic from template logic.

9. Change Detection Optimizations

Consider adding challenging calculations into the ngDoCheck lifecycle hook. And if possible cache them for as long as feasible.

10. Use Route Guards on the Navigation

Angular route guards are interfaces provided by angular which when implemented allow us to control the accessibility of a route based on conditions provided in class implementation of that interface.

CanActivate: Checks whether the component can be accessed or not
CanActivateChild: Checks whether the child component can be accessed or not
CanDeactivate: It asks for permission to discard the changes
CanLoad: Checks before load feature module
Resolve: It pre-fetch the route data to make sure that data-related navigation is available or not.

11. Use environment variables

Angular provides environment configurations to declare variables unique for each environment. The default environments are development and production. I will upload soon a tutorial on how to configure environment variables.

The major benefits of using environment variables are:

Easy configuration
Better security
Fewer production mistakes

12. Use lint rules

Linting forces the program to be cleaner and more consistent. It is widely supported across all modern editors and can be customized with your own lint rules and configurations.

One very famous and simple example of using Lint rules is to disable console logging in production simply by using "no-console": [true, "log", "error"] .

A more detailed tutorial on how to configure lint rules is on the way!

13. Documentation

Always document the code, as much as possible. It is a good Angular practice to document methods by defining them using multi-line comments on what task the method actually performs and all parameters should be explained.

/**
* This is the foo function
* @param bar This is the bar parameter
* @returns returns a string version of bar
*/
function foo(bar: number): string {
return bar.toString()
}

Finally, I hope you find this list helpful,

What should be in a readme file?

Oumayma JavaScript Developer — Mon, 27 Dec 2021 13:57:17 +0000

A readme file is the first file a person will see when they encounter your project, so it should be briefly detailed and pretty. It gives the user (who visits your repository) a brief idea about what the project is about, what your project can do, how to run it, etc.

As projects vary, we can establish that there's no one right way to structure a good README. But there is one very wrong way, and that is to not include a README at all.

It is also important to note that when you're writing your project's README, it should be able to answer the what, why, and the how of the project.

Here you will find the basic information to add to your readme file.

Title

This is the name of the project. It describes the whole project in one sentence and helps people understand what the main goal and aim of the project are.

Description

A good description should mention:

The purpose of your application
Links to other projects that this application might be linked to.
Technologies used.

How to Install and Run the Project Locally

Include the steps required to install your project and also the required dependencies if any.

Provide a step-by-step description of how to get the development environment running.

If possible provide steps to run the projects in containers including the commands used.

Provide Relevant Links

Provide a link to the application or documentation such as swagger in case of a web application of an API.

Wrap-up!

There you have it, few steps to get you started with writing your first readme file.
For more details on how to write one, here's a good link to get started.

Guidelines for better Pull Requests

Oumayma JavaScript Developer — Fri, 24 Dec 2021 15:26:24 +0000

A pull request is a good way to propose and collaborate on changes to a repository. Writing good pull requests and having an effective workflow will increase a team’s productivity and minimize frustration.

Expected benefits of a good PR:

It tends to be reviewed quickly;
It reduces bug introduction into codebase;
It facilitates new developers onboarding;
It does not block other developers;
It speeds up the code review process and consequently the product development;

1. Before Opening the Pull Request

The checklist below aims to reduce the noise among the author and their reviewers.

Name the branch accordingly to the team’s convention.
Explicit whether the Pull Request is a draft (or WIP).
Go through the changed code looking for typos, irrelevant comments, debugging pieces of code, trailing whitespaces, etc.
Combine multiple commits into one to make it look like a story (or a task).
Rebase your branch onto master and upstream branch.

2. Make Smaller Pull Requests

Making smaller pull requests is the #1 way to speed up your review time. Because they are so small, it’s easier for the reviewers to understand the context and reason with the logic.

Small PRs are :

Reviewed more thoroughly and quickly.
Easier to merge.
Less wasted work if rejected.

Here are some ideas to make it easier to make small PRs:

Extract refactoring to a separate PR.
Split big features into parts (even if they wouldn’t be user-facing).
Make git add --patch your friend! ( it allows you to go through your code one more time before committing).

3. Clear Title and Description

When creating a pull request you should care about the title and the description as a way to provide an overview of why the work is taking place with links to the JIRA ticket and any other relevant services.

Start the description by stating the purpose of your work. Something in the lines of :

This is a spike to explore…
This simplifies the display of…
This fixes handling of…

Do not assume full familiarity with the story or work that has been done. Imagine that the code reviewer is arriving in your team today without knowing what is going on, and even so, they should be able to understand the changes. Remember that anyone in the company could be reading this Pull Request, so the content and tone may inform people other than those taking part, now or later.

Mention colleagues or teams that you specifically want to involve in the discussion, and mention why. (“/cc @person for clarification on this logic. @ops, any concerns with this approach?”).

For client-side changes, add some screenshots or gifs for changes or animations.

Similarly, a useful summary title (instead of just the issue key) makes it clear to the reviewer what’s being solved at a high level, which takes off one extra step for the reviewer.

Keep the title short, but expressive enough to signal what the reviewer can expect.

3. Code review

As a reviewer:

Prioritize PR review.
Make an effort to read the description and understand how the feature works.
Use positive language as opposed to neutral. (If the content is neutral, we assume the tone is negative.)
Write clear comments. Describe the issue, why you don’t agree (mistakes, errors, violations against conventions, performance risk, security issues, etc.) , and propose other solutions to simplify and improve the code. Don’t be afraid to ask questions.
Write good and bad comments. If you like a piece of code don’t hesitate to let the developer know!
Use a checklist to try to catch any errors, bad practices.
Pull the code locally to test the acceptance criteria of the feature and the performance before approving.

As a developer:

Two reviewers are better than one! don’t merge your code until at least 2 reviewers approve.
Do not change the code while reviewing.
Answer all comments and explain your point of view.
A common axiom is “Don’t take it personally. The object under review is of the code, not you.” Assume the best intention from the reviewer’s comments and be aware of how hard it is to convey emotion online. If a review seems aggressive or angry or otherwise personal, consider if it is intended to be read that way and ask the person for clarification of intent, in person if possible.

Finally,

To sum up, keep in mind that a good pull request is reviewed fast, which means merged fast!