Forem: Yash

Add open with Neovide Option in Windows 10

Yash — Sun, 09 May 2021 06:01:04 +0000

Open Notepad or your preferred text editor
Copy the script below

Windows Registry Editor Version 5.00
; Open files
[HKEY_CLASSES_ROOT\*\shell\Open with Neovim]
@="Edit with Neovim"
"Icon"="C:\\Program Files\\neovide\\neovide.exe,0"
[HKEY_CLASSES_ROOT\*\shell\Open with Neovim\command]
@="\"C:\\Program Files\\neovide\\neovide.exe\" \"%1\""

; This will make it appear when you right click ON a folder
; The "Icon" line can be removed if you don't want the icon to appear
[HKEY_CLASSES_ROOT\Directory\shell\neovide]
@="Open Folder as Neovim Project"
"Icon"="\"C:\\Program Files\\neovide\\neovide.exe\",0"
[HKEY_CLASSES_ROOT\Directory\shell\neovide\command]
@="\"C:\\Program Files\\neovide\\neovide.exe\" \"%1\""

; This will make it appear when you right click INSIDE a folder
; The "Icon" line can be removed if you don't want the icon to appear
[HKEY_CLASSES_ROOT\Directory\Background\shell\neovide]
@="Open Folder as Neovim Project"
"Icon"="\"C:\\Program Files\\neovide\\neovide.exe\",0"
[HKEY_CLASSES_ROOT\Directory\Background\shell\neovide\command]
@="\"C:\\Program Files\\neovide\\neovide.exe\" \"%V\""

Paste it in the text editor
Save the file as neovideOpenFolder.reg
Run the file.

Now you can have a nice open with Neovim option.

If it doesn't work check the paths of Neovide in the script.
You can also change Neovim to Neovide if you like.

Disclosure of JavaScript Closures.

Yash — Sun, 24 May 2020 13:30:06 +0000

JavaScript closures are tough to wrap your head around the first time you encounter them. Some developers might come off forming a wrong mental model about closures as it is very easy to get closures in the wrong way.

Perhaps reading the code that uses closure in a linear fashion can be an easily misleading way to form a wrong mental model about it. In this post I am going to disclose what closures actually are.

Let's start by understanding how the JavaScript engine parses our code.

How JavaScript Engine Works

It goes by the code line by line.
Any function declaration and variables it finds is put in the global memory.
(Putting these functions and variable in the global memory is called hoisting.)

   // Values like below are put in the global memory.
   const someVariable = 123

   function myFirstFunc() {
       console.log('This is my awesome function')
   }

   const mySecondFunc = function mySecondFunc() {
       console.log('This is my awesome function')
   }

At this point the JavaScript code is compiled, and the engine will again go line by line.
When the engine hits a function it checks its global memory for the function and creates a temporary environment for that function which is known as its execution context.
The fact that the function is pulled out from the global memory is worth emphasizing which you'll learn soon why.

The execution context has 2 parts - a memory and a place to execute the statements inside the function. This execution context is unique to the function.
The function is also added at the top of call stack, the global() always rests at the bottom of this call stack. The call stack basically tells the engine what to work on, so, the function on the top of JavaScript is what the engine will work on.

All the arguments passed in the function are evaluated (if you pass in a variable a as an argument which was assigned a value of 1, then a is changed to 1),
These evaluated arguments are added to the memory part of the execution context of the function. In the memory these arguments are saved by the labels given according to the parameters of the function.

   function myElegantFunction(myParameterOne, myParameterTwo) {
       console.log(myParameterOne, myParameterTwo)
   }

   myVariableOne = 'Hello'
   myVariableTwo = 'World'

   myElegantFunction(myVariableOne, myVariableTwo)

   /** myElegantFunction(myVariableOne, myVariableTwo)
    is changed to 
    myElegantFunction('hello', 'world')

    Let's see the memory part of the execution context of myElegantFunction,
    ----------
    myParameterOne: 'Hello'
    myParameterTwo: 'World'
    ----------
    As you can see how these arguments are saved according to the name of the parameter which we            referenced in the function declaration.
   **/

Now the statements inside of the function are executed one by one, if it contains any variable it is first looked in the memory part of the execution context of that function if the variable is not found then the engine tried to search for it in the global scope.
The function is removed off the call stack and the global() proceeds to run the JavaScript code.

To give more clarity I have made a small video animation visually explaining this process exclusively for this post.

By now you must have understood how the call stack, execution context, and memory work all together to achieve the task of running your code. Keeping the above procedures in mind, this is the perfect time to introduce you to closures.

Getting close to closures

Let's consider a function -

function counterFunction() {
  let counter = 0;

  function increaseCounter() {
    counter++;
    console.log(counter);
  }

  return increaseCounter;
}

The function counter is a higher-order function as it returns another function namely increaseCounter.
Let's declare assign this function to a variable.

const count = counterFunction();

When JavaScript is executing the above line, it puts the function increaseCounter in its global memory. So what goes in the global memory with the label count is -

count: function increaseCounter() {
    counter++;
    console.log(counter);
  }

// NOTE: Use of ':' (colon) is representational.

Here's where things start getting interesting when we call count

count(); // Output is 1
count(); // Output is 2
count(); // Output is 3

JavaScript is in fact, getting the function from the global memory,

function increaseCounter() {
    counter++;
    console.log(counter);
  }

Here's another animated video for the execution of the above code.

As the execution context starts executing the statement, it encounters the variable counter, the first place it checks is the memory of the execution context itself and the next thing it should check is the global memory.

Anyone familiar with the working of the JavaScript engine should think it is impossible to get variable counter.

This is where closures come into the play. Let's go back to where we stored counterFunction().

const count = counterFunction();

When the increaseCounter is stored in the count variable. The count variable literally carries with it the variables from the function counterFunction, which is the function increaseCounter was *return*ed from.

In this state it is said that - increaseCounter has a closure over counterFunction.

The value of counter is coming from the closure which increaseCounter carried. Every time we call counter++ we don't touch the counter in the counterFunction we update the counter variable in the closure of increaseCounter.

To demonstrate the fact that counter being updated is not the part of counterFunction() here's a neat trick.

const count = counterFunction()
const countTwo = counterFunction()

count() // Output is 1
count() // Output is 2
count() // Output is 3

countTwo() // Output is 1
count() // Output is 4
countTwo() // Output is 2

If counter was being updated from the counterFunction() instead of the closures of the function count and countTwo then the output of countTwo() must have added on to the value updated previously by the count() function. But it does not happens.

Conclusion

I mentioned earlier how easy is it to develop a wrong mental model about closures, it is because we tend to read code linearly and tend to confuse lexical scoping to closures, they are similar but not the same.

Closures are a part of the scope of a function. You can be more clear about closures if you use the JavaScript debugger in your browser's developer tool to inspect where the variables are stored.

Chrome literally shows the closure to be a part of that function's scope which they are. Closures are not a link between two functions.

#discuss Do you read JavaScript Specification? Why should someone read JavaScript Specs?

Yash — Thu, 21 May 2020 15:34:38 +0000

I was talking to someone and they said that you need not read the JavaScript specs until you're implementing a parser or something.

I want to know the opinions of other devs on the topic.

Here's a link to the JavaScript specifications

5 Tools Every Open Source Software Must Use.

Yash — Thu, 14 May 2020 12:54:59 +0000

So you made an open source software but it has no systematic way of showing fancy test fails when someone makes a pull request or other amazing things some good open source software are able to accomplish. In this writeup I am going to cover a few tools to make your open source software awesome!

1. Testing

Popular Tool(s) - Mocha, Jest, Cypress etc.

Testing is really important; you don't want to make changes to your code and regret your app failing at production and that too on Friday.

If you're making a library or framework or any other tool then the importance of testing is a lot more than for other apps.

Basically, in a test you define what you expect a function to do, if the function misbehaves you immediately tell by seeing the test fail.

Check this awesome talk by Tomasz to learn more about tests.

2. Linting

Popular Tool(s) - ESlint etc.

ESLint checks the readability of the code and even formats it to make it more readable.

For example - someone might miss an indent randomly somewhere and if it gets to GitHub or any other place where you host your code then the indent results in loss of readability of code.

3. Code Coverage

Popular Tool(s) - Codecov, Istanbul etc.

If you have been in the dev community for a while you must have heard people say things like - "We have achieved 100% Test Coverage."

These tools check how much of your code is being tested. So if someone decides to delete a few tests because the tests are failing for their changes you immediately known as code coverage has suffered.

If used popular they will also warn about not meeting a targeted coverage for the software.

It is recommended to target for 100% test coverage.

4. Compilation and Postprocessing

Popular Tool(s) - Babel, Webpack, Uglify, etc.

You probably don't want your code to break on old machines and browsers. That's where tools like babel come in to play, Babel will compile your code in to old versions of JavaScript, for example, you wrote an arrow function, but old browsers do not support arrow functions. Babel will convert that arrow function to a regular function.

Uglify.js minifies your code by removing the extra spaces, comments and even shortening the variable names.

Extremely size efficient libraries like Preact rely heavily on uglifier and use very custom settings for the best optimization.

5. CI/CD

Popular Tool(s) - TravisCI, GitHub Actions etc.

Ever saw fancy test failing in a GitHub PR, these are features that a CI/CD tool will provide.
Awesome Tools like Travis allow you to Test and Deploy your application. So, whenever you push your code to the repo or someone create pull request, Travis CI will run the code and check if the tests are passing or not.

If the tests of a PR are failing then it will give an error right there in GitHub that the tests are failing.

On an ending note, there are many other popular must have in libraries but the 5 tools I have listed are the ones that I personally really like to have.

Thanks for reading this post.

About Me

I am a 17-year-old passionate web developer and I go by @yashguptaz on the internet. Be sure to direct message me on Twitter for any help you want.

Understanding Git: Open Source for Novice.

Yash — Tue, 05 May 2020 07:08:27 +0000

Perhaps you hear the term "Open Source" often. You are impressed by people contributing to large complex Open Source Software. But you don't know where to start, even good first issues seem to be very hard to approach.

I recently made a CLI Tool called tell-about and open-sourced it. So as an open-source maintainer of my tool with little fame I got some experience so I have decided that I am going to help you understand how to contribute easily.

yashguptaz / tell-about

A CLI Tool that help you know about npm pacakges right in the command line.

So, what's the best way to start?

I recently saw a tweet by Ben Awad -

Ben Awad

@benawad

if you're a beginner and having a hard contributing to open source, I recommend starting your own project first then coming back to it

18:39 PM - 04 May 2020

I have to agree with it. I have decided to create a series of write-ups that help people understand the system of open-source software. The series is going to cover everything from introducing git to creating a fully automated repository on GitHub.

Understanding Git

When I was a beginner, I always wondered what a pull request, a branch, and all those things were exactly. With all the complexity of git, it was hard for me to wrap my head around how everything in a complex project like React worked.

Understanding how Git works is the first step to understanding how you can start to contribute to open-source software.

Need of Git

For those who don't know, git is a VCS or Version Control System. Now, take a moment to think about the version. There are so many people trying to contribute to one single project.

At a given time there are many people working on a single project but different features.

If they all were to make changes directly to the project then there would be a huge mess,

Let's try to understand with an example - 'A' changes lines 1 through 10 to incorporate a feature A and 'B' changes lines 5 through 15 to incorporate a feature B.

'A' updates the code first. 'B' updates the code second.

In this situation, the code of B works while the code of A is broken because B has now overwritten lines 5 through 10. Now take this example and magnify the situation with 25 people.

Sure, they won't always be making changes on the same lines. But a lot of times they will be.

This is where our VCS comes in to play. The VCS is used to maintain a main stable version. A stable version is a version where all features work properly. This main stable version is generally called Master. Let's learn about Branches to solve this issue.

Branches

Let's now see how VCS solve this problem of merging two features.

With git we can create a duplicate of the current Master version, this duplicate is called a branch. So, this time 'A' starts working on feature A on branch A. 'B' does the same.

'A' makes the changes on branch A and merges their branch to the master version.

Well and good. Now, 'B' also tries to merge their branch but... we run into the same problem again except we have git to back it up. Git tells B that there is a merge conflict, B quickly identifies that A has made some changes and now he has a couple of options to resolve this merge conflict -

He pulls (gets) the changes of A from the master branch to their branch, keeping the code of A, B adds their code after the code of A and keeps the code of both.
While merging to the master branch B manually modifies the code to keep both feature A and feature B.

Generally, there will be a third person, a maintainer (or a senior) of the repository to regulate. The maintainer will review the code and ensure that B's code is good by reviewing it.

More often than not, while contributing to big open source projects you will find that they also have tests. Tests checks if the output of code is as expected. And if any tests are failing it is fairly common to have a bot like Travis CI to tell if the code is broken. Which further mitigates the risk of breaking the code.

So, in the scenario that A has some features and B breaks the feature the Travis CI bot will tell that tests of feature A is failed.

Forks

If you've used any amount of GitHub you must have noticed a fork button on GitHub repositories.

Branches are internal, even the master version I talked about is a branch, giving access to everyone to modify branches could be a big danger. That's where forks come in to play.

When you create a fork of a repository you create a copy of that repository that belongs to you.

The difference between Forks and branch is that when you create another branch it is the copy o f a branch. But when you create a fork it is a personal copy of the whole repository, you can modify it in any way you want and it won't effect the main codebase of the project.

After you make changes to your fork you can request the maintainers of the project to merge your changes with the main project. That brings us to the next topic.

Pull Requests

Pull request might seem a bit complicated after you see it on GitHub. It may seem so complicated that you might neglect the simplicity of its name.

A Pull Request is a request to the maintainers of a repository to pull (merge) your changes. Pull simply means pulling changes from your fork or branch to another branch which is the master branch most of the time. A request is a request.

A Pull Request compares 2 branches, the 2 branches maybe master branch and a branch from your fork or master branch with any other branch.

Ending Note

Hopefully, this blog post gives you a really good way to start comprehending the working of git in open source projects. In my upcoming posts, I will be covering how you can contribute and even set up your own fully automated open source project on GitHub.

Thanks for reading till the end :)

Make sure to follow me on dev.to so that you're updated about my upcoming posts.

I am active on Twitter and I am known by the username @yashguptaz. Be sure to hit me up on Twitter if you want any help. A follow-on Twitter is really appreciated :)

🍛 What the heck is Currying? ft. JavaScript

Yash — Wed, 18 Mar 2020 08:23:54 +0000

I know that you’re salivating, perhaps the dev world has become too delicious with JAMStack and now I’m talking about curry? So before you starve to death with these wonders of dev world let me introduce you to what currying is in general.

Currying was named after Haskell Curry, what currying essentially means is taking a function that takes multiple parameters and converting it into a function which only takes one parameter and returns a function which then takes the next parameter.

Currying is not JavaScript specific it is also a mathematical thing just like function (Remember good ol' f(x) ?)

// Not curried
const add = (x, y) => x + y

// Curried
const add = x => y => x + y
const addFive = add(5)
addFive(6) // 11

As you can see using Currying we were able to have functions that are more definite in what they do, this in turn greatly simplifies our code.

With the help of currying, we can essentially pre-load functions with an argument in order to receive a new function that remembers those arguments.

Let's make a function that can help us in Currying other functions.
Now pay close attention,
This function is going to take a function fn and return a function $curry that takes a single argument and performs the operation of the function fn.

Let's do this step by step

// This function takes a function `fn` as a parameter.
function curry(fn) {
  // Let us determine the arity of `fn`
  // Arity is the number of parameter taken by `fn`
  const arity = fn.length

  // ...
}

function curry(fn) {
  const arity = fn.length

  // Let's return the $curry function.
  // Let's have all the arguments ( ...args ) being passed in $curry
  // Remember we are returning a function so we can pass args in it.
  return function $curry(...args) {
    // ...
  }
}

function curry(fn) {
  const arity = fn.length
  return function $curry(...args) {
    // Let's return the function with all the passed arguments.
    // This code maybe stupid until you read the next para...
    return $curry.bind(null, ...args)

    // ...
  }
}

We can't just keep returning functions and functions we need a result. Let it be adding digits together and getting the output.

Let's add a condition for this.

function curry(fn) {
  const arity = fn.length
  return function $curry(...args) {
    if (args.length < arity) {
      return $curry.bind(null, ...args)
    }
    return fn.call(null, ...args)
  }
}

By comparing the length of the arguments args.length we can know how many arguments have been passed in the function.

Things will become more clear as I demonstrate how we are using the curry function to curry other functions which take multiple parameters.

For the sake of simplicity let's take an add function which takes 3 values (parameters) and add them together.

const add = (x, y, z) => x + y + z

const curriedAdd = curry(add)

const addFive = curriedAdd(5) // args.length = 1

const addFiveAndSix = addFive(6) // args.length = 2

const output = addFiveAndSix(8) // args.length = 3

// The funciton can be called now as `args.length` < arity is false.
console.log(output) // 19

args.length is able to give us the number of arguments because of return $curry.bind(null, ...args) . The $curry function contains all the arguments passed above the any given instance.

I hope this clears everything about how the function is working. If you have any other doubts you can tweet them to me.

( @yashguptaz )

Adding Taste to your Code.

Currying allows a wonderful phenomenon called partial application.
According to Wikipedia partial application can be defined as -

Partial Application refers to the process of fixing a number of arguments to a function, producing another function of smaller arity.

The definition is pretty straightforward, we reduce the number of parameters a function takes by currying it.

Let's curry a well-known function map and see how it changes our life.

// Before Currying
const allTheChildren = elements => map(elements, getChildren)

// Let's curry map
const map = curry((fn, f) => f.map(fn))

// AFter Currying
const allTheChildren = map(getChildren)

The effect becomes really obvious when you are using map multiple times. And that's how we reduce a ton of boilerplate code.

You can curry pretty much any function that takes more than one parameter. And use Partial Application.

Isn't it amazing? Although I am a beginner at currying I found it exciting to share. If you want to share something or ask a question or would like to solve or understand something together, you can hook me up on twitter. I am @yashguptaz on the internet.

Follow me on twitter as I tweet about my experince with Functional Programming.

Quality Server-Side Rendering with React

Yash — Sun, 22 Dec 2019 04:43:09 +0000

Server-side rendering is a term that we often hear in the react world, there are a lot of frameworks that help us with server-side rendering like Next.js and Gatsby. Server-side rendering can add various additional improvements to our application but at the same time complicate things even more. There are situations where it is useful and other situations where it can cause trouble.

When I first heard the term server-side rendering I thought it had something to do with the backend of the application, but it turned out it was something totally different than that.

We will start by comparing how does loading and rendering a website differ in the client-side rendering and server-side rendering.

Loading Application while Client-Side Rendering it

JavaScript, CSS, and other Libraries are loaded.
ReactDOM.render() starts.
Fetching of data is started and requests are sent, the application gets the data from external APIs.
The whole Virtual DOM is created. It gets reconciled with the real DOM. React traverses the whole Virtual DOM and renders it to the real DOM.

The issue with client-side rendering is that this process takes a very long time. That's where server-side rendering comes in to play.

In server-side-rendering instead of initially creating the Virtual DOM, we send an HTML element initially rendered instead. This is usually done by ReactDOMServer.renderToString() method.

We avoid the process of loading the Virtual DOM and reconciling it with the real DOM instead we put HTML directly into our DOM with server-side rendering.

Although there are few things that we can do to optimize the performance of a client-side rendered application.

Optimizing Client-side rendered application

Load the layout or the skeleton part first.
Cache the skeleton part with service workers.
Show a certain part of the layout even if the majority part of the layout is dynamically added like the top navbar which has a login button.
You can avoid loading the dynamic parts of the application initially.

For the sake of user experience please always load the skeleton first, if the height or width is not fixed with the element please load it at the last.

When using Twitter to search users it always shifts the user being displayed below after it completely loads and whenever I am about to click I click the wrong place.

This is a terrible practice and should be avoided.

Dependencies are better pre-loaded with Server Side Rendering

Say we use some dependency A in our application using which triggers the fetch of dependency B.

With client-side rendering, one has to fetch dependency A and then B which is slow.

With server-side rendering, you can present your application with dependency A and avoid fetching an extra dependency.

Better SEO with Server Side Rendering

Server-Side Rendering makes crawlers easy to crawl pages. Google indexes the page with HTML faster than those with JavaScript rendering DOM elements.

This is because people can easily trick google having a lot of text with JavaScript but in actuality, when they render the page they have a very little amount of relevant text which can also be used to mislead people. So indexing pages that render with the help of JavaScript is tricky which is why people use Server Side Rendering for better SEO.

Trade-offs of Server-Side Rendering

Maintainability Nightmare: You need to maintain 2 DOM trees.
Some libraries are not aware of server-side rendering so they make an assumption about the presence of window objects which can sometimes, make the library unusable.
The complexity starts to increase exponentially with a server-side rendered application as they don't have access to the window object, things like local storage are not present so complexity increases with data and state management.
React itself is not very server-side compatible.
Time-to-interaction is very high with server-side rendering. This is because HTML is loaded faster than JavaScript. So there might be cases where user is unable to click a button when it is loaded.

Server-side rendering is best suited for parts of the application that do not require dynamic interactions.

Thanks to Sudhanshu Yadav. He helped me with much of the content of the blog. Please do follow him on Twitter.

If you have any opportunities for me or want to connect to me with Twitter, I am @yashguptaz on the internet.

Thanks for Reading.