You have a frontend application which gets deployed to production, for millions of people to use. The source code is private, you have your development workflow all sorted out, the build and release process is working fine without any glitches, but one day you get a vulnerability report from a researcher that your source code can be recreated because your .git folder is reachable through the production URLs, like https://myapp.com/.git/ . …

The other day I was trying to understand potential security issues with exposing secrets or tokens in the url, and how OAuth implementations protect against that. Turns out, there are a few legitimate concerns, and a few patterns in OAuth that specify how to send tokens securely.

When the browser (or any other client) makes a request to a server, there are some intermediate servers which your request goes through, and they can see the URL, unless you use https. These can be any intermediate routers, CDNs, reverse proxies, etc. Some of these might be malicious and if they can…

<button
  ...
  onClick={() => this.props.handleClick()}
/>

Usually when I see code like this in a PR, I suggest the dev to change it to:

<button
  ...
  onClick={this.props.handleClick}
/>

because of unnecessary anonymous function being created in every render, which although isn’t as big a deal, but why not fix it if you easily can?

Though I have been doing this for quite some time now, it was only recently that I realized that my understanding about both these snippets being functionally similar, is a bit flawed, though it works as expected in most of the cases. …

Most charts usually require some kind of reference line to compare the current plotted data against. For example, a budget chart can have a reference line for 70% of the budget, to display when the expenses went over the prescribed limit and another reference line for 100% of the budget, Or , a chart showing the monthly rainfall in cm can have a reference line for average rainfall in cm to show in which months the rainfall was more than average. …

As we have already seen here, Recharts allows you to render any svg element as a child element of a chart container and only accepts a svg element when customizing Labels or ticks and other customizable elements (with the exception of Tooltip, as Tooltip is rendered outside the svg chart, so it can accept regular html), but there are a lot of things that are just way easier to render with html. svg allows this using the foreignObject svg element and since Recharts can render any svg elements, Recharts allows this as well. …

The top level charts in Recharts act as a container for other elements which can be rendered inside it. Some examples are LineChart, BarChart. These charts act as top level containers for other elements like Line, Bar, Tooltip, ReferenceLine, ReferenceDot, XAxis, etc. …

In Recharts, you provide data to the top level container, and on appropriate children you specify the key from which that particular child should get its data, using the prop named dataKey. This is only applicable for components that actually make use of this data, like Line or XAxis, YAxis, but does not make sense for components that do not need this whole data. For example, ReferenceArea, ReferenceLine etc only need some slice of this data, which does not require the same mechanism as dataKey. For these components that data is passed on or handled by Recharts internally.

Accessing data using dataKey:

Passing…

An animated circle, or another animated shape, is generally used in charts to attract user attention, to entice user to click or hover on something. Some shapes and animations are much easier to achieve in css, and other complex animations and shapes can be easier to achieve in svg. But when working with a charting library, it is much more important to understand which of these css or svg animations can be integrated well with the library api, or whether the library provides another in-built way to achieve the required functionality.

Let’s try to create a pulsating circle with Recharts…