DEV Community: Prashant Andani

Difference between npm install and npm ci

Prashant Andani — Fri, 15 May 2020 06:20:11 +0000

The main differences between using npm install and npm ci are:

The project must have an existing package-lock.json or npm-shrinkwrap.json.

If dependencies in the package-lock do not match those in package.json, npm ci will exit with an error, instead of updating the package-lock.
npm ci can only install entire projects at a time: individual dependencies cannot be added with this command.

If a node_modules is already present, it will be automatically removed before npm ci begins its install.

It will never write to package.json or any of the package-locks: installs are essentially frozen.

How many of you received Hacktoberfest T-shirt?

Prashant Andani — Sat, 30 Nov 2019 06:07:36 +0000

How many of you received Hacktoberfest Swag? Send Pics and be proud of your contributions to the open-source community.
:)

Function currying for the dynamic length of params i.e Implementing Add(1)(2)(3).....(n)()

Prashant Andani — Tue, 08 Oct 2019 15:01:46 +0000

Currying refers to the process of transforming a function with multiple arities into the same function with less arity. The curried effect is achieved by binding some of the arguments to the first function to invoke so that those values are fixed for the next invocation. Here’s an example of what a curried function looks like:

// add(2)(3);

and the function definition is

function add(a) {
  return function(b) {
    return a + b;
  }
}

The above solution works for the currying for a function with two params

How would we achieve if there are more dynamic no. of params

i.e add(2)(3)(4)(5)....(n)()

Let's write a generic add function that takes n no. of params.

  function add(a) {
   return function(b) {
      return b ? add(a + b) : a;
   }
  }

😇 One-liner solution with an ES6 arrow function

const add = a => b => b ? add(a + b) : a;

🙌 🙌🏻 🙌🏼 🙌🏽 🙌🏾 🙌🏿

Implementation of ES6 Map() function

Prashant Andani — Tue, 08 Oct 2019 09:57:43 +0000

//implementing map function

/* Implemetation */
const arrayMap = (arr, fn) => {
  const arrTemp = [];
  for (var i = 0; i < arr.length; i++) {
    arrTemp.push(fn(arr[i], i));
  }
  return arrTemp;
};

/* Usage */
// const arr = [1,2, 3];
// const iterator = each => each + 1;
const result = arrayMap(arr, iterator);
//console.log(result);

Frontend Architecture Decision making and checklist

Prashant Andani — Tue, 01 Oct 2019 09:18:19 +0000

Before getting started with the Architecture planning for a Front end development of a project. Things to be sure and Architect the code base accordingly
Here is the checklist to worth looking in to.

** This is the first set of thoughts **

Responsiveness (Web, Mobile etc) Multi-Browser support (chrome, firefox, safari with versions) Is IE Support required?
1. Feature flagging (A/B testing of a set of features for user groups based on location etc before releasing to all) https://dzone.com/articles/feature-flag-driven-development
2. Role-based access
3. SEO - Server-side rendering
4. PWA - Mobile Web (Offline first, Network first)
5. Realtime data sync - Is realtime data syncing is required, in that case, we can think of Web socket or any other approach.
6. Security - What are the security measures to be considered
7. Internationalization
8. Accessibility - Accessibility is the practice of making your websites usable by as many people as possible.
9. Performance first - https://medium.com/yld-blog/performance-driven-development-c7fc030cc060

PWA vs React Native (Decision on choosing over one another)

Prashant Andani — Thu, 19 Sep 2019 06:35:24 +0000

PWA vs React Native

Whenever building cross-platform apps, two things come to a mind, PWA or React Native. As these are the hottest technologies out there(You are free to consider others).

If you are an app developer today, which one should you prioritize and build for?

What decisions go into choosing one over the other?

The below points help in making the right decision on which one to choose or suits best for your needs.
Wait!!!

If Cost and Time aren't your problems, you should build both a PWA and a React Native solution and design the architecture of your app in a way to re-use as much logic between the PWA, React Native-Android, and React
Native-iOS projects as possible.

The PWA gets you the widest reach where any device with a browser can view your app.

The React Native app gets you richness/depth where you get to take advantage of a device's native UI controls for maximum performance and familiarity for users.

Here are some thoughts.
Are you going mobile-first or everywhere first?
If your goal is to target mobile devices (Android and iOS) only via the app store, then go with React Native.
If you want to reach the widest range of users and devices via the browser, go with a PWA.

If you want the lowest-cost option for your development team, then a PWA wins.
You write your app once using HTML, CSS, and JS and it will run pretty much everywhere a browser is available. If a browser isn't available (think smartwatches and so on), you can always build a hybrid app using a WebView that wraps your PWA and gets it on those tiny little screens:
To make your PWA work well across all of these devices, you do need to ensure your app is responsive/adaptive and relies on progressive enhancement. Knowing the range of devices you'll need to support upfront is key.

If you want the best UI responsiveness and performance, go React Native.

React Native uses the iOS and Android native UI controls, so you get to use the platform controls users are familiar with along with the snappy performance a non-HTML UI layer provides.

With a PWA, the interactions are always going to be a bit clunky - the animations will be less rich, multi-touch will be less responsive, the lack of multithreading will always keep your interactions fighting for priority with other things your app is doing, and so on.

If you care about low-end devices, PWA is slightly better than React Native.
While the UI layer in React Native is made up of platform controls, the underlying data communication is all JavaScript.
If you have an app that deals extensively with data, the slow JS throughput on lower-end Android devices is a very noticeable bottleneck that often makes the UI feel clunky.

React Native creates a native app package (~usually tens of megabytes in size!) that needs to be installed prior to the user seeing even a single pixel from your app.

PWAs load in the browser immediately.

This may be less of a problem in areas where you have plenty of cheap/fast bandwidth and device storage. If you are targeting large parts of the world where bandwidth and storage are problems, then a PWA is better. Installing an app from the app store is a major commitment, so giving users a lite version that is an instantly-available PWA and a richer version that is a React Native-based app (installed via the app store) is the best approach.

I do realize this suggestion falls under the magical world where there are no time and resource constraints and you can build multiple versions of your app, but sometimes that is the best solution. This is what Twitter did!

What are you (or your development team) skilled in?

There is always a nontrivial cost to learn new technology and train others on it. Both PWAs and React Native have their steep learning curves when you want to create a great user experience (especially at the critical last-mile), so keep this detail in mind as a factor.

Is your app consumer-focused or enterprise-focused?

Consumer apps tend to need a high degree of visual polish, and that tends to favor React Native because you get to work with native UI controls.

Enterprise apps should be visually awesome as well, but that is often not a differentiator since most enterprise apps can't be substituted for something similar. A good PWA with (optionally) good offline capabilities could meet most enterprise requirements.

Do you need access to native device APIs?

PWAs are limited by the browser sandbox, so you can't go beyond what the Web APIs provide access to. If all you need is a webcam/camera, microphone, geolocation, etc., then you are good. If you need deeper access to customized hardware and sensors, richer Bluetooth support, and so on, React Native allows you to access the native hardware. You could take the Hybrid App approach using a WebView and fully extend your PWA with the code for accessing native device capabilities, but that will require you to still build a native app (even if Apache Cordova or Ionic make that a breeze) and go through the app stores.

Desktop or Mobile or both?

If you only care about the desktop, then React Native won't help. I do realize there are desktop ports of React Native available, but most aren't officially maintained by the React team and have various gaps that you will need to address yourself. A PWA will run well on desktops, but if you need more native access to lower-level APIs, the browser security sandbox will block you from getting that access unless you decide to rely on a WebView inside a native app (similar to Electron).

SCSS Mixins for responsive design, utility classes

Prashant Andani — Thu, 19 Sep 2019 05:58:17 +0000

Problem:

When I start any new web application, I worry about responsive design. How am I going to handle the different view for different screen sizes? Always used to desire of having bootstrap kind of row/column spacing without having bootstrap.
Always wanted to also have utility classes for spacing (paddings, margins).

Easily rememberable class names which could make my problems disappear.
SCSS Mixins for responsive design, utility classes above specified problems must have been faced by almost all the web application developers. If you’re using some CSS framework, they provide you different solutions for these. But, assuming you have SCSS mixins which generate you those classes and solves your problem in around 50 lines of CSS code instead of importing a complete framework (eg. Bootstrap).

Don’t worry, I have a solution to your worries. If you’re not using SCSS, then convert SCSS code to CSS using online converters.

Please import this file

https://github.com/malothnaresh/css-utilities/blob/master/common.scss
Usage:

Spacing utility classes:

The first mixing in this file creates most of the required spacing utility classes. The unit used is rem. And every count you specified is 0.25rem * #{count}.

Eg:

p-0: Padding 0rem to all sides;
m-0: Margin 0rem to all sides;
p-1: Padding 0.25rem to all sides;
m-2: Margin 0.50rem to all sides;
p-3: Padding 0.75rem to all sides;
m-4: Margin 1rem to all sides;
pl-5: PaddingLeft 1.25rem;
mr-6: MarginRight 1.50rem;
pt-7: PaddingTop 1.75rem;
mb-8: MarginBottom 2rem;
All class names are:

Padding all sides: [p-0, p-1, …p–20]
Margin all sides: [m-0, m-1, …m-20]
Padding Left: [pl-0, pl-1, …pl-20]
Padding Right: [pr-0, pr-1, …pr–20]
Padding Top: [pt-0, pt-1, …pt–20]
Padding Bottom [pb-0, pb-1, …pb–20]
Margin Left: [ml-0, ml-1, …ml–20]
Margin Right: [mr-0, mr-1, …mr–20]
Margin Top: [mt-0, mt-1, …mt–20]
Margin Bottom: [mb-0, mb-1, …mb–20].
Row / Columns Divider:

The second mixin in this file gives you a row divided into 12 columns (Bootstrap’s style of row/column design pattern). Every row is “display: flex” with 12 columns (flexes).

Eg:

This content would be 3 columns on large screens, 6 columns on medium screen, 12 columns on small and extremely small screen

All class names according to screen sizes:

Extremely small screens (max-width: 480px):

col-xs-1, col-xs-2, col-xs-3, col-xs-4, col-xs-5, col-xs-6, col-xs-7, col-xs-8, col-xs-9, col-xs-10, col-xs-11, col-xs-12.

Small screens (max-width: 768px):

col-sm-1, col-sm-2, col-sm-3, col-sm-4, col-sm-5, col-sm-6, col-sm-7, col-sm-8, col-sm-9, col-sm-10, col-sm-11, col-sm-12.

Medium screens (max-width: 1125px):

col-md-1, col-md-2, col-md-3, col-md-4, col-md-5, col-md-6, col-md-7, col-md-8, col-md-9, col-md-10, col-md-11, col-md-12.

Large screens (Desktop / Monitor screens):

col-lg-1, col-lg-2, col-lg-3, col-lg-4, col-lg-5, col-lg-6, col-lg-7, col-lg-8, col-lg-9, col-lg-10, col-lg-11, col-lg-12.

Hope this bootstraps your styling…

Medium Doc Link: https://medium.com/@cryptoipl/scss-mixins-for-responsive-design-utilities-classes-4194a25e7a99

Contribution by: Maloth Naresh

Quick guide to CSS Units (px, em, rem)

Prashant Andani — Wed, 18 Sep 2019 09:45:33 +0000

Here are some commonly used CSS Units with the pros and cons of each of them.

PIXEL(px):
Pixels are fixed in size. 1px = 1 dot on a computer screen. It is an absolute unit of measure

Pros:
Pixels are preferred when we want to develop pixel-perfect web applications (Non-responsive in nature)

Cons:
Pixels cannot be used to build a responsive website. If we need to build a responsive website, then excessive use of media queries would have to be used in order to achieve a responsive design which might become cumbersome. This approach will also lend towards missing few viewports.

When to use?
Pixels come in handy especially when we have fixed divs, like the height of a header or footer remains the same irrespective of the viewport.

POINT(pt):

Points are usually used for things to be printed on paper ie for print media.
Same as a pixel.
Fixed measure and not scalable.

EM:
EM is always equal to the current font-size. It is scalable in nature.

Pros:
Since it is scalable, can build responsive websites.
If font-size is equal to 16px, then 1em = 16px, 0.5em = 8px and 2em = 32px.

Cons:
Em causes an issue when we have nested elements.

Let us have a root at 100% that is 16px. Let there be a child who should have 12px, so we specify the value as 0.75em. Now if we have another child inside this, it will get a font size of 0.75em of 12px, that is 9px. To avoid this, we need to again specify it

html { font-size: 100%; } ul { font-size: 0.75em; } ul ul { font-size: 1em; }

We need to pay a lot of attention when nesting of elements take place.

PERCENT(%):

Percent unit is similar to em.

Pros:
As the name suggests, percent of something. If nothing specified, it will take % of the browser's width or height.
Useful for building Fluid Layout.

Cons:
If the child elements are fixed width, and if a parent is in %, it can result in unexpected layout. Need to be careful with nested elements.
NOTE: When base size increases, % and em automatically increases but pixel and pt remain the same.

REM:
Stands for Root EM. REM is relative only to the root size whereas em is relative to its nearest parent.

Pros:
Rem always takes the root size into consideration irrespective of the nesting of elements.

Cons:
Browser default size for Rem is 16px. Hence it becomes difficult to remember the rem values.

10px = 0.625rem 12px = 0.75rem 14px = 0.875rem 16px = 1rem (base) 18px = 1.125rem 20px = 1.25rem 24px = 1.5rem 30px = 1.875rem 32px = 2rem

2.Partial support in IE 10.

VW, VH:

These units are viewport width and viewport height respectively. 1vw = 1/100 th of the viewport width and
1vh = 1/100 of viewport height.
It is a relative measure.

NOTE: There major difference between % and vh/vw is that VW unit determines its size based on the width of the viewport. Browsers calculate the viewport size as the browser window, which includes the space for the scrollbar whereas in %, it's only the width of the html element.
If we set 100vw, then it will include the html element+body+scrollbar width.

For heights, if we use %, it can cause an issue as the size in % of an element is determined by its parent height. We can have an element fill the entire screen only if its parent also fills the entire height of the screen.
But,
.test {
height: 100vh;
}

Here, no matter how the element is nested, it will be relative to the viewport dimensions. The problem of scrollbar won't be an issue since most webpages don't have a horizontal scroll.
Hence, when dealing with widths, the % unit is more suitable. With heights, the vh unit is better.