In a previous blog post I wrote (here), I talked about how important it was to determine the runtime complexity of the code you use to tackle problems. Developers are always looking for the most efficient solution. In some cases, the solution you come up with immediately is not the most performative one and you will want to rewrite the code completely; in other cases, however, you do not necessarily have to completely scrap the code you wrote initially.
Let’s take the Fibonacci algorithm as an example. The Fibonacci series is an ordering of numbers where each number is the sum of the preceding two. …
Whenever you tackle a problem in code, there is a good chance that the solution you come up with will not be identical to solutions arrived at by other developers. Maybe one developer likes building character maps, while another likes bubble sorting. Depending on what you’re working on this MAY (notice the caps there) not be a big deal. However, in many cases you DO need to pay attention to exactly which solution you choose. Why? Isn’t the point to just solve a problem, no matter how it’s done? Obviously, since I’m asking the question, the answer is clearly no…you are not just looking at solving a problem. …
I’m not sure about everyone else, but when I started churning out React apps (ha!) using create-react-app, I didn’t pay much attention to why exactly my index.js file looked like this:
In quite a few of my React apps, I’ve pulled images from some outside API to then be displayed on a page to users. It’s a fairly simple process, BUT there is almost always an issue when it comes to rendering the images; oftentimes the images that are returned are large and not uniformly formatted.
So you have a perfectly wonderful React app with elegant code and snappy styling to display whatever it is that you want to your users. But what is it that you want to display? For most developers, at least some of the information displayed on their app must be requested from some outside API.
But it is NOT the job of the React library itself to make an API request; indeed, as a library, React is really only about showing content (HTML) to users and handling user interaction. The job of making a network request falls to some separate piece of code inside our app. …
I’ve always been a fan of arrows…I love efficiency and arrows are efficient, communicating so much with so little. Turns out, that appreciation extends to Javascript arrow functions as well.
To understand my love affair with arrow functions, we need to think about a common error that arises when coding a React app. Let’s say we have a simple Search Bar component in our app and as we are building it out, we would like to test our form submission by console logging whatever the input is. Now, an old school way of handling this might look like the following:
I created a React app a while ago in which users could record wildlife sightings and, by inputing the latitude and longitude of their sightings, could create pins on a map with information about the location and organism recorded (click here for the demo if you’re interested). I utilized the Google Maps API for that project and needed to request an API key. I requested my key, had fun creating my app and committed my code to GitHub. A short while later, I received an ominous email:
Many developers were skeptical of the “new kid” when React was announced in 2011. However, it has proven to be an extremely successful library, with more and more companies, such as Airbnb, Uber, Netflix and Twitter, adopting it for their own products. It became so popular, in fact, that the framework was extended to the mobile universe with React Native.
So What Is React Native?
Like React itself, React Native is Javascript-based…but its power lies in the fact that you can build natively rendered mobile applications for various platforms using the same codebase. In other words, you write code once and it can be used to develop both iOS and Android apps. …
Well, not ACTUAL classes…
For anyone who has had experience with creating a React app, the question of whether to use a Functional component versus a Class component is a familiar one. The traditional way of thinking went something like this: if you have a simple component, go ahead and make it Functional; anything else should essentially be a Class component. Class components were more versatile, allowing you to take advantage of LifeCycle methods and to hold state.
One of the most deceptively simple concepts in Javascript is the idea of Value vs. Reference. Understanding how data types behave is important for debugging code on the job, as well as during tech interviews, as this is a question that seems to come up often.
Let’s first rewind to Javascript 101. There are two categories of data types in Javascript, primitives (null, undefined, string, boolean) and objects (object, array, function).
