Forem: Cristofer

Create a nice-looking input range with only CSS!!

Cristofer — Wed, 29 Apr 2020 17:52:59 +0000

We all as a developers know the importance of the <input /> tag element, without it, we wouldn't have a way to receive any input from the user.

There are a lot of types that we can use on an input element, and each one, change the behavior of the element, here's a list of the most common types of input's:

text: The default value. A single-line text field.

button: A push button with no default behavior displaying the value of the value attribute, empty by default. If it's inside a <form> tag, it will submit the form when pressed.

checkbox: A check box allowing single values to be selected/deselected.

color: A control for specifying a color; opening a color picker when active in supporting browsers.

email: A field for editing an email address. Looks like a text input, but with validation parameters on supported devices.

password: A single-line text field whose value is obscured. Will alert user if site is not secure.

number: A control for entering a number. Displays a spinner and adds default validation when supported.

hidden: A control that is not displayed but whose value is submitted to the server.

*No image for obvious reason xD*

range: A control for entering a number whose exact value is not important. Displays as a range widget defaulting to the middle value.

As we can see, there are a lot of types that we can use, you can check them in deep here

`<input type="range" />`

In this post I'm going to show you how to modify the default style for the range input type so it looks better.

NOTE: All the code below works only on Chrome and Opera, TBH I didn't even try to fix any visual bug on any other browser.

The very basic implementation of an input range looks like this:



<input type="range" />

This will render the same as the saw above:

We have available some extra properties when using this element:

value: String representation of a number, although it can't be an empty string (""). The default value is always halfway between min and max properties. This is how is calculated:



defaultValue = (rangeElem.max < rangeElem.min) ? rangeElem.min
               : rangeElem.min + (rangeElem.max - rangeElem.min)/2;

max & min: The maximum and minimum value permitted.
step: The stepping interval.
list: The id of the <datalist> element that contains optional pre-defined options.

Ok! enough with HTML Input 101, let's put a style on that input!.

First we need the basic html structure, something like this:



<div class="container">
  <datalist id="custom-list">
    <option value="1"></option>
    <option value="2"></option>
    <option value="3"></option>
    <option value="4"></option>
    <option value="5"></option>
    <option value="6"></option>
    <option value="7"></option>
    <option value="8"></option>
    <option value="9"></option>
    <option value="10"></option>
    <option value="11"></option>
  </datalist>
  <input type="range" min="1" max="10" step="1" list="custom-list"/>
</div>

The markup above will render this:

It renders a hash mark for each <option> of the <datalist> element.

Thumb and tracker

On any slider control, we have 2 element that we can interact to, the thumb and the tracker, the thumb is just the little widget that let you drag and drop along the track:

They're called Shadow DOM elements and we can actually style them with CSS, so let's start by that.

Enable user agent shadow DOM

I recommend you to enable the Shadow DOM on your browser, since we can't inspect this elements by default, and sometimes it's easier to just manipulate the element directly from the developer tools instead of the common process: change, save & reload.

I'll show you how to activate it using Opera, but this works the same on Chrome, and I'm pretty sure that on FF it's just as easy as it is on Opera (is just a checkbox, shouldn't be a big issue on any browser).

So, first open the Developer Tools (F12) in your browser, once its open, either press F1 or use the kebab menu (A.K.A 3 dots menu) and click on the "settings" option:

This will open the settings section. Next, we only need to check the option "Show user agent shadow DOM" under the Elements list:

Now, if we inspect the input, instead of looking like a regular input element:

We'll see the markup a bit different:

The input has elements inside, which represent the tracker and the thumb, now will be easier to inspect and modify the styles for this elements.

Styling

Let's start by styling our container element and removing the default look & feel of the input



.container {
  position: relative;
  max-width: 450px;
  overflow: hidden;
}

input[type="range"] {
  -webkit-appearance: none;
  width: 100%;
}

To style the thumb and the tracker we have the pseudo-elements:

::-webkit-slider-runnable-track: Selector for the tracker.
::-webkit-slider-thumb: Selector for the thumb.

IE and FF also have their pseudo-elements: :-moz-range-track and ::-moz-range-thumb for FF, ::-ms-track and ::-ms-thumb for IE

Using this, we'll apply our custom styles, let's start with the tracker:



input[type="range"]::-webkit-slider-runnable-track {
  width: 100%;
  height: 1.2em;
  cursor: pointer;
  border: 1px solid #29334f;
  overflow: hidden;
}

We set a border around the tracker and hide all the overflow content, now should look something like this:

I know, I know! It looks really ugly, so lets fix that by applying some style to the thumb:



input[type="range"]::-webkit-slider-thumb {
   height: 12px;
   width: 45px;
   cursor: pointer;
   -webkit-appearance: none;
   border-bottom: 1px solid #29334f;
   box-shadow: 0 0 0 red, -40px 0 0 red, -85px 0 0 red, -130px 0 0 red,
      -175px 0 0 red, -220px 0 0 red, -265px 0 0 red, -310px 0 0 red,
      -350px 0 0 red, -390px 0 0 red, -409px 0 0 red;
   background: black;
}

First remove the default look & feel for the thumb, then we create a box shadow (10 actually) for the thumb and position them one behind the other, so now the input looks better:

Remember, we have the shadowDOM active, if something doesn't look the same, just inspect the element and change the style as you need.

Now, all we need to do is put some style in the <datalist> element:



#custom-list {
  display: flex;
  justify-content: space-between;
}

#custom-list option {
  position: relative;
  background: white;
  top: 18px;
  border-left: 1px solid black;
  border-right: 1px solid black;
}

Our datalist have a display flex and its items are align with a space between them, next, we just position all the datalist element upfront our input range (it was at the top). Finally we just set left and right borders on each option element. This is how it looks like:

Even though our input range is start taking shape, still looks a little weird, so let's fix it.

The first problem, is the first option element with 2 borders, we don't need that, so let's hide it



#custom-list option:first-of-type {
  visibility: hidden;
}

But that's not enough, we also need to fix the height of option so the top border of the option element will overflow a little bit the top border of the tracker.

You can base on the height we define for the thumb, in this case: 12px



#custom-list option {
  ...
  min-height: 12.5px; # just a little bit more
}

If we look at the end of our input range, we still se a weird border, something like "]" (is actually our input track), to fix that, let's set overflow: hidden to the .container element:



.container {
  ...
  overflow: hidden;
}

And last but not least, let's remove the ugly focus effect that the input have by default:



input[type="range"]:focus {
  outline: none;
}

And there you go!! Now you have a great looking input range, using only a few lines of CSS.

Before

After

You can check the full code here.

Happy coding!! 💻🤓

RedwoodJS: Intro & Web Side

Cristofer — Tue, 14 Apr 2020 15:32:11 +0000

Redwoodjs is an opinionated serverless web framework for Javascript, that allows you to create applications using the JAMstack.

Since it make you follow some code conventions (that will explore in this post) while coding, the developer experience is really lovely and I'm pretty sure after reading this post you will like to try it out!

First Impressions

Topics like: ReactJS, Apollo (GraphQL), Prisma, Storybook, Babel, Webpack, are really popular among web developers, and there's a good reason for that:
They all make the developer experience great!

Don't forget to mention that each tool resolves many other issues on it's own environment

So now, imagine someone describe to you, their React frontend app, statically delivered by CDN, that talks via GraphQL to their backend running on AWS Lambdas around the world, all deployable with just a git push command?

Really cool uh?, Well this last paragraph it's exactly how RedwoodJS is officially defined, so no more presentations needed, let's start digging into it!.

JAMstack

If you already understand what's the JAMstack you can skip this section and just jump ahead to the Going through the web side section.

JAM stands for JavaScript, API & Markup, and like you can imagine, it means that your app (if it applies) should be just about Markup (HTML) and Javascript (Using the API of the browers) and nothing else.
It's just a way to think about the workflow of an app development, by removing a backend server.

Nowadays the web need apps that are high-performant, have less security risk, and of course, there's a less cost when trying to scale them.

How do you achieve this? By making it small and simple from the begging, which happens to be one features of the JAMstack.

One of the many ways to define the JAMstack that I like more is the one from Mathias Biilmann, CEO & Co-founder of Netlify:

"A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup"

It's very likely that you already have interact with one of these apps, or even work in one if you have use any of the static site generators that are out there.

For obvious reasons, the JAMstack doesn't fit for all the apps, so how we can know if our app applies to this stack? Easy, if your app doesn't relies on a tight coupling between client and server, then you are on the right path.

Also, if you are using a server-side CMS (Drupal, Wordpress, etc..) or building a monolithic app with Node, Ruby, etc... the JAMstack is not what you are looking for.

So now you have a basic idea of what the JAMstack is, now let's check RedwoodJS.

Going through the web side

RedwoodJS uses node and yarn, so you will need those to be installed on your computer. Check Prerequisites Here

To create an app just run:

yarn create redwood-app ./my-app

Let's start talking about how RedwoodJS organize the code.

Code Organization

By default, a RedwoodJS app has 2 sides: web and api

my-app
|__api/
   |__prisma/
   |__migrations/
   |__src/
      |__functions/
      |__graphql/
      |__services/
   |__dev.db
|__web/
   |__public/
   |__src/
      |__components/
      |__layouts/
      |__pages/
   |__index.css
   |__index.html
   |__index.js
   |__Routes.js

Inside the api folder, we have 3 more directories:

prisma/: Contains the database schema and the seeds to pre-populate your database.
migrations/: This folder will be created after running your first migration, and it contains snapshots of your database.
src/: This directory contains another 3 directories inside:
- functions/: This is where all the labmda functions live, you will find some other files to configure your Graphql API.
- graphql/: Contains Schema Definition Language (SDL) files of your grapql schema
- services/: Here you'll find all the business logic of your app, but in an abstract way, so it can be consume across all your app (web & api) in a consist way.

Now for the web folder, we have a more simple structure:

public/: This folder is for static resources
src/: This is where all the code for our React app will live:
- components/: Besides your regular React components, RedwoodJS stores the Cells components in this directory too (we'll explore them later)
- layouts/: Not much to say here, just use it for all the layouts that your app could have
- pages/: This pages components, usually are wrapped by a layout component, and it's what the user see when they land on a url.

RedwoodJS call these top-level folders (web & api) sides, but underneath they are Yarn workspaces, and of course there are a couple of features around using them.

The CLI

RedwoodJS comes with a handy CLI app that let you run some task, like create an scaffold, create a database, running a migration, and so on.

Here is the list of some of the commands I use more:

yarn redwood dev or yarn rw dev: Starts a development server
yarn rw test: Run test suite using Jest
yarn rw db save: Create a new migration
yarn rw db up: Run any new migration and update the schema
yarn rw db seed: Seed the database
yarn rw generate <resource>: A generator for the given resource:
- cell
- component
- layout
- page
- scaffold
- sdl
- service

We'll look more into the resources later.

Alias Path

Like I've mention, following some code conventions allows us to increase the developer experience and we can see an example with how RedwoodJS handle the routes.

Let's create a new page using the cli:

yarn rw generate page hello /

As you can see, the page generators accepts 2 parameters, one is the name of the page, and the other one is the url of that page.

After running this command, you'll see a new directory inside web/src/pages/ called HelloPage, as you can see RedwoodJS automatically takes the name you specified, capitalize it and append Page to create the folder name.

Let's see how our page component looks like:

const HelloPage = () => {
  return (
    <div>
      <h1>HelloPage</h1>
      <p>Find me in ./web/src/pages/HelloPage/HelloPage.js</p>
    </div>
  )
}

export default HelloPage

As you can see, we no longer need to import React at the top of each component so we have more cleaner components.
You'll also notice that all the react component are functional component, and this is because they use React Hooks a lot, you still can use class though, but they don't recommend it.

Now let's take a look to the Routes.js file:

import { Router, Route } from '@redwoodjs/router'

const Routes = () => {
  return (
    <Router>
      <Route path="/" page={HelloPage} name="hello" />
      <Route notfound page={NotFoundPage} />
    </Router>
  )
}

export default Routes

As you can see, there's a new Route component that points the / url to the HelloPage component. We can also notice a few other things happening on this file:

<Router> & <Route> component are coming from redwoodjs.
HelloPage & NotFoundPage components are not imported anywhere in this file.

So how does it know where to find this component? Well, since pages are what the user see when they land on a url, its gonna be obvious that all the pages component would need to be imported here, so RedwoodJS automatically import it for you at build time, so you don't need to have a huge Routes.js filled with import ... statments.

This feature also works with nested folders, but there's a rule: the have to be uppercase

'src/pages/HomePage/HomePage.js'         -> HomePage
'src/pages/Admin/BooksPage/BooksPage.js' -> AdminBooksPage

Named routes

Run this to create another page:

yarn rw generate page about

This time we just specify the resource name without the route, when we do this, Redwood automatically uses that same name, to define the route:

const Routes = () => {
  return (
    <Router>
      <Route path="/about" page={AboutPage} name="about" />
      <Route path="/" page={HelloPage} name="hello" />
      <Route notfound page={NotFoundPage} />
    </Router>
  )
}

RedwoodJS uses the <Link> component to handle the navigations between pages, let's take a look on how to use it:

import { Link, routes } from '@redwoodjs/router'

const HelloPage = () => {
  return (
    <div>
      <h1>HelloPage</h1>
      <Link to={routes.about()}>See about</Link>
    </div>
  )
}

The <Link> components accept a prop called to, and as you can see we passed it a function from the routes object. This is a named route function calling this function will generate the correct url, and maybe you already figure it out, but the name of the property inside the routes object is coming from the name prop that we set on the <Route> component:

<Route path="/about" page={AboutPage} name="about" />

Additionally, the to prop also accepts a string, but a great thing about having this name route, is that we can change the url any time and all the links will be updated without having to do anything else.

Cells

Another good thing about Redwoodjs are Cells components.

When you work with React, is very common to step into the next scenario:

You have to implement a simple listing page, that fetch data from your server, and then renders a list of items, easy!, but then you start asking yourself, what should I show when there's no items, or when there's been an error while fetching the data, or event what you show to the user while fetching this data!?

All the sudden you have to implement a single listing component that handle up to 4 different states.

The bad part is when you have this listing page for each resource of your app.

Well RedwoodJS found this use case to be very repetitive and that's why they create a Cell component.

Cells provide a simpler and more declarative approach to data fetching.

That's how RedwoodJS define a Cell component. Okay, let's see them in action.

The next example would probably looks weird since we have not talk about the api side, but for now, you can just think that there's a grahpql model called post and all the backend works outta of magic.
We'll talk about the api side on the next post

export const QUERY = gql`
  query {
    posts {
      id
      title
      body
      createdAt
    }
  }
`

export const Loading = () => <div>Loading...</div>

export const Empty = () => <div>No posts yet!</div>

export const Failure = ({ error }) => (
  <div>Error loading posts: {error.message}</div>
)

export const Success = ({ posts }) => {
  return posts.map((post) => (
    <article>
      <h2>{post.title}</h2>
      <div>{post.body}</div>
    </article>
  ))
}

Ok, I know there's a lot going on here, so lets just untangle all:

There's a variable called QUERY been exported from this file and it holds a gql query
There are 4 components been exported also: Loading, Empty, Failure and Success, each of one render a different UI representing the state of the component.

So what happens here, once React has made the render, RedwoodJS will execute the grahpql query from the QUERY variable while it renders the Loading component, once the call is done, it will render either Empty, Failure or Success component based on the query response.

Additionally you could use the beforeQuery and afterQuery lifecyles to do modify the props before they go to the Success component.

You can omit the Empty and Failure components, and after an empty data response, the Success component will be rendered or if there's any error will be outputted to the console.

Wrapping up: Web Side

Even though there a lot of libraries and frameworks out there, TBH RedwoodJS looks really unique to me when it comes to a fast development, great developer experience and huge performance for develop web apps using the JAMstack.

The sad part? RedwoodJS is still in alpha version, so it's not production-ready yet, but they have an interesting roadmap, so feel free to try it out or even better contribute to the framework

On the next post we'll look into the API side of the framework and check what RedwoodJS offer us!

Thanks for reading! 👋🏻👋🏻

Beacon API

Cristofer — Thu, 13 Feb 2020 18:59:41 +0000

Modern browsers are increasingly venturing into the native interaction with the hardware, they offer us an small, but helpful list of APIs to have fun.

Some of them have a more native interactions, and some of them are more like utilities that can help developers.

This is the case for the Beacon API

The Problem

It's very likely you'll find yourself, at some point of your web developer career, working with analytics. This type of scripts often need to do something (eg. reporting) when the document triggers an unload event, normally would be a call to a server maybe to let know that a user just left the page just before checkout (ouch!)

The first piece of code that comes to my mind when I encounter this scenario looks like this:

window.onunload = function userLeave() {
  // Do the http request to my analytics server
}

Well, turns out that browsers, ignore asynchronous http calls that happen during an unload event.

Again, first solution that comes to my mind: let's make it synchronous. Well, although it works, doing a synchronous action inside the unload event will force the browsers to wait until this event has completely finish, therefore the next page will feel slow to load.

There are other techniques to handle this scenario, but they all involves a bad code practice and affect the user navigation

Send a Beacon! 🗼🗼

To solve this issue, the browsers offers us the Beacon API.

The navigator object has a method called sendBeacon(), this method receives 2 parameters: url and options.

The url parameter represents the url of the server you want to send the request, and the options parameter (optional) can be a simple String, or if you want to send more complex data, you could also pass an ArrayBufferView, Blob, DOMString, or FormData.

This function schedules an http POST request using the parameters you passed in (url and options), it returns true if the http call was successfully scheduled, returns false otherwise

window.onunload = function userLeave() {
  const crashData = new FormData()
  const url = 'https://my-analytics-server/'

  crashData.append('userID', '123');

  navigator.sendBeacon(url, crashData)
}

Beacon requests use only HTTP POST and do not require a response.

Beacon requests are guaranteed to be initiated before the page unloads.

You should check out all the examples from the docs to see how this can help you in many other cases!

Thanks for reading 🤚

Render dangerous content with React

Cristofer — Mon, 03 Feb 2020 21:30:55 +0000

FYI All the content of this post suits best for some edge cases, and the solution proposed here is probably not the more safe way to do it.

Cross-site Scripting (XSS Attacks)

Among all the web vulnerabilities, one of the most common is cross-site scripting, this type of vulnerability allows the attackers to inject scripts on the page to get access to any sensitive information the browser and the site are sharing (cookies, tokens, etc...).

This attack occurs when the data entered is coming from an untrusted source or the data that is sent to the user include dynamic content without been validated first.
Although there are limitless varieties of XSS attacks, Javascript XSS attacks seems to be popular among hackers.

Types of XSS Attacks

There are 3 types of XSS attacks:

Stored XSS Attacks occurs when the injected script is store on the server (i.e. store on a database) so each time the user request a something from the server
the malicious script is sent to the client.

Reflected XSS Attacks happens when the malicious script is reflect on the web that's vulnerable, this could be due to a click on an email link that's malformed or any other external source.

DOM Based XSS Attacks is a vulnerability that occurs on the DOM (Document Object Model) instead of the HTML.

Let's say you have this code on your app:

<script>
   document.write('<h1>My URL:</h1>: '+ document.baseURI);
</script>

Now, imagine someone visits your site using the URL https://www.nicesite.com/index.html#<script>alert('test')</script>, the script will be executed because the code above writes whatever comes on url to the document using document.write.

We can point one of the main differences between this type of XSS attack and the Stored and Reflected: The servers can't stop this attack, since the hash (#) part of the url is not being sent to the server on the request.

Prevent XSS Attacks

For most of the XSS attacks the solution is simple, just sanitize your input data, even if comes from a trusted source.
Doing this will ensure that no matter what's the input or output, is always secure.

Javascript offers us plenty ways to interact with the DOM, so we can works with dynamic content in an easy way, but we need to be careful on how to use it, since it can make vulnerable our websites.

Inputs & Outputs

Here's a tiny list of the most common input and outputs that can be dangerous to use.

Inputs	Outputs
`document.URL`	`document.write`
`document.documentURI`	`element.innerHTML`
`location.href`	`element.src`

React and cross-site scripting

Nowadays all the web apps required some dynamism, from having a multiple step form that shows different question depending on your answers to a simple tables that filter out information, this is where Javascript enters to the equation.

Back in time, when Javascript vainilla was enough to get everything done (which still is, we just 'syntax-sugar' it), one of the way you could handle insertion of dynamic content, was using innerHTML property.

Element.innerHTML:

The Element property innerHTML gets or sets the HTML or XML markup contained within the element

So, you can set the HTML content from an element using this property, but what happen when the content has an script inside?

const content = 'Christofer'
el.innerHTML = content


const newContent = "<script>alert('You've been hacked')</script>";
el.innerHTML = newContent

The first 2 lines create a variable that holds a plain string, then using innerHTML set the content of an element to be this value, so far so good, nothing harmless here.

On the next 2 lines of code we do the same, but this time, the string value is html-like with a <script> tag within it, so what would you think will be the output?

Well, if you though that this will result on an alert prompting to the user that he has been hacked, well you are wrong.

HTML5 specifications says that scripts inserted using innerHTML shouldn't execute.

Easy to be safe

React follows the philosophy "easy to be safe", that's why we as developers should be explicit if we want to go for the unsafe path, and this is the case for the dangerouslySetInnerHTML prop.

This prop allows you to inject dynamic html to an element, all you need to do is pass and object with a single property: __html, with a string html-like of what you want to render:

function App() {
  const html = `
    <div>
      <h1> Injected html</h1>
    </div>
  `

  return (
    <div  dangerouslyInnerHTML={{ __html: html }}/>
  )
}

As you can see, seems a little odd that you have to pass an object when it could be a simple string, but this is done intentionally, to remind you that it's dangerous and you should avoid using it as much as possible.

innerHTML vs dangerouslySetInnerHTML

Writing React doesn't mean that you can't use the features that Javascript offer us, you can use innerHTML to add the dynamic html to a react component and it will work the same (both will update the node with the html), but it can lead to undesired performance issues.

React uses a virtual DOM and a diffing algorithm to compare what's been updated and re-render the content, this process is called reconciliation.

Using dangerouslySetInnerHTML you can tell React to ignore all the dynamic html during reconciliation

When you use innerHTML to set the content, all the dynamic html that was generated is included in the reconciliation process, aside performance issues, React could wrongly update the dynamic html.

Since both properties works the same (in fact dangerouslySetInnerHTML implements innerHTML to set the content) they both share kinda the same vulnerabilities, hence the importance of sanitizing your input sources.

Render the danger

Now what happens when you want to use dangerouslySetInnerHTML but also need to execute any script tag that comes inside the html? That's against HTML5 specifications, but if we dig a little bit more on what innerHTML do to inject the html we can found something interesting:

The specified value is parsed as HTML or XML (based on the document type), resulting in a DocumentFragment object representing the new set of DOM nodes for the new elements.

This DocumentFragment is a lightweight version of the document, it can have child nodes, the main difference is that since is a fragment, is not actually a part of the active/main document.

We can create a DocumentFragment using the document.Range API.

const html = `
  <h1>Fragment</h1>
`
const node = document.createRange().createContextualFragment(html);

This code snippet will create a DocumentFragment object, parse the value of the html variable and store the result on a variable called node. All we have to do is render this variable:

element.appenChild(node)

If we translate all of this to a React component we end up with something like this:

import React, { useEffect, useRef } from 'react'

// InnerHTML component
function InnerHTML(props) {
  const { html } = props
  const divRef = useRef(null)

  useEffect(() => {
    const parsedHTML = document.createRange().createContextualFragment(html)
    divRef.current.appendChild(parsedHTML)
  }, [])


  return (
    <div ref={divRef}></div>
  )
}

// Usage
function App() {
  const html = `
    <h1>Fragment</h1>
  `

  return (
    <InnerHTML html={html} />
  )
}

This way we could pass a string with html content that includes <script> tags, and those will be executed (works with <script> .. content .. </script> and <script src="file.js" />)

dangerously-set-html-content is a tiny (297B Gzipped), no-dependencies, library that allows you to render dynamic html and execute any scripts tag within it.

1) Add it to your project:

yarn add dangerously-set-html-content
// or
// npm install dangerously-set-html-content --save

2) Start using it:

import React from 'react'
import InnerHTML from 'dangerously-set-html-content'

function App() {
  const html = `
    <div>
      <h1>Fragment</h1>
      <script>
        alert('this will be executed');
      </script>
    </div>
  `

  return (
    <InnerHTML html={html} />
  )
}

Of course this doesn't prevent any attack (in fact, does the opposite of that), but sometimes this functionally could be what you are looking for.

I built this because I actually needed this functionality.

Conclusions

All the web is full of vulnerabilities that can cause you headaches if you are not aware of how to prevent them. Mostly of the common frontend libraries already handle a few of these in a way, so you don't have to worry about it‌ but still is good to know what we are dealing with as front-end developers.

Additionally of what React offers us, there are several techniques that can help you to prevent an attack, so if you are having a problem of this type just head to the docs and you'll probably find the solution.

While 99% of the time all this magic behind React works perfectly for us, sometimes we can found ourselves struggling with it, but at the end is just Javascript so embracing both will help us to find the solution to our problem.

Thanks!

How do I write React

Cristofer — Mon, 03 Feb 2020 19:15:04 +0000

I've write a lot of Javascript through my short career, and one the many things that I have learned is that, bad code still works on Javascript.

What I like about Javascript is how flexible it is, you can split your code into different files, put them anywhere you want, pass the path to the require() function and you are good to go, you don't need a strict folder structure for the app to be working.

This is good when you are been introduced to programming, but this is also one of the reason why people don't get along with Javascript.

React doesn't help with this problem, in fact it could complicate things even more, that's why I've decided to follow some rules when writing React.

I describe them in this blog post, some of them might seem odd to you, some of them not, take what works for you and pass it to the next!

Javascript linter

Even though this post is about React, we can't write clean React code, without writing clean Javascript code first.

Every time I write Javascript I like to use a linter to check some basic code style rules.

I used to use ESLint, which is pretty common among JS developers, but then I found StandardJS.

StandardJS has some special rules (it doesn't use semi-colon, you can't ignore a rule), that make it look like really strict but it's precisely this set of standard rules what makes it great.

It's really easy to use, all you have to do is add it to your project:

yarn add standard
// or
// npm install --save standard

You don't need a configuration file to start using the linter.

There's a lot of discussions about programming style in js (tabs vs spaces, semi-colons) that's why I like standard, because it picks some 'standard' rules and that's all you have, no more, no less therefore no more discussions.

Automatically fix your problems (just use the --fix flag).

I always create 2 npm scripts: npm run lint and npm run lint:fix.
The first script is what I use more often, that shows all the errors with information about the line and file where they occurs.
The second script is just to automatically fix the common errors, but I still try to manually fix as much as possible.

Git pre-commit hook.

Sometimes when I'm more strict about the programming style, I create a pre-commit hook for the project, that can save some review time.

Initializing a react project

The npm registry is one of the biggest databases of public and private libraries for javascript. It offers a command line client to use all the features like, download, upload and do some other things, that allow you to interact with several javascript packages.

There's one particular package that I use a lot when creating a react app: npx.

This lib allows you to execute the package binaries files, it executes the <command> you passed in, following an specific order:

Local node_modules/.bin folder
A central cache
Install it and execute

Why `npx` instead of `npm`?

Honestly, I just don't like to struggle with all the versions and deprecations stuff, with npx I ensure that the library that I'm using is on the latest stable version.

npx <command>

You can use npm to download React and start your project from scratch (configure Webpack to do all the fancy stuff you are used to have 'out-of-the-box') or you can use create-react-app (CRA).

This library allow you to bootstrap a React project. It has all the configurations needed for a rapid development with React (like hot reload, ES6 support, etc...)

One of the good things about CRA, is the ability to have all the latest patches and features with a single bump version of your react-scripts dependency (which is what CRA uses), so you don't have to worry for this anymore. CRA also allows you to have your custom setup by ejecting your application, this action will give you the full control of the Webpack configuration, so you can twist it and do whatever you want with it.

npx & create-react-app

So now you know all the benefits of using npx and create-react-app, you can start figuring out how we can mix up these 2 libraries to simplify the creation of a React application.

Each time I start a new React project I just run:

npx create-react-app awesomeApp

That command will download (the latest-stable version) CRA and executes it, that's why we need to pass the name of the project we want to use (awesomeApp).

Organize app structure

CRA offers a very basic folder structure for your app:

 awesomeApp/
  |__public/
  |__src/
    |__App.css
    |__App.js
    |__App.test.js
    |__index.css
    |__index.js
    |__logo.svg
    |__serviceWorker.js
    |__setupTests.js
  |__.gitignore
  |__package.json
  |__README.md

Some apps that I have in production are so simple that this folder structure is enough to work.

When I know that a project will be a little more complicated than that, I change the folder structure so that it's easy for me or any other developer make changes.

I split my components in two types:

Components
Containers

Following this idea, the folder structure that I use, looks like pretty much like this:

 awesomeApp/
  |__public/
  |__src/
    |__components/
      |__ui/
    |__containers/
    |__utils/
    |__App.css
    |__App.js
    |__App.test.js
    |__index.css
    |__index.js
    |__logo.svg
    |__serviceWorker.js
    |__setupTests.js
  |__.gitignore
  |__package.json
  |__README.md

Components

This is where I put all my UI components, that means, components that doesn't do to much of a logic, they are just there to present some information to the user and depend a little bit from the props that we passed in.

The ui/ folder holds all the components that are related to the User Interface (i.e. custom component for commons elements like <CustomInput /> instead of <input /> or <CustomImg /> instead of <img />)

Containers

This is where I put the smart components. A smart component is the one that controls the state of a particular part of the app. I use this type of components to wrap the most of the base markdown of the pages.

Also I create a new folder called utils/, which I use for all the utility functions that I'd use across the app.

Note: When I work with React Native, I just rename the containers/ folder to pages/, seems better name for me.

Organize Code

The index.js file contains all the code that register the service working and also render your app. So this file is basically your entry point, I suggest not to touch this file unless you really have to.

Then we have the App.js file, which is the React component that's been rendered on the index.js file. I use this file as my main React file, and I try to keep it as simple as possible.

Most of my App.js file look like this:

import React from 'react'

import MainContainer from './containers/MainContainer'

function App() {
  return <MainContainer />
}

export default App

We can point up some things here:

1) It's a functional component instead of a class component.
2) It does nothing but render a main container component
3) Export a default function which is the actual component

1) It's a functional component instead of a class component:

I used to use class components all the time, so that I could have an state and control everything with the lifecycles of React but since hooks came out, all my components started to shrink a lot, and I liked that, so I haven't needed a class component anymore.

2) It does nothing but render a main container component:

I always try to keep this component clean, unless I need some initial data that's coming from outside (i.e. API calls). So this will only return the main container, which will have all the business logic.

I often use this function to wrap my app with a High Order Component (HOC), like react router or any css theme, so that's available for any children component.

3) Export a default function which is the actual component

Each time I jump to an existing project and try to figure out all the imports a single file is doing, is really annoying to be searching if there's any export in a particular line, or if they default export a function that's been declare in line 128, that's why I prefer to have all my exports at the end of the file, so each time I wanted to see what's been exported, I just go the end of the file.

Props and State

I used to use class components for my containers/pages and functional components for all other component, this way I could separate the concerns for each type of component.

Now since hooks are live, I found myself writing cleaner components using functional components and hooks.

Class components

A simple class component of my own looks like this:

import React from 'react'

class HomeContainer extends React.Component {

  state = {}

  componentDidMount() {
    // Initialization of component's state
  }

  customMethod = () => {
    // 'this' is safe
  }

  render() {
    const { prop1, prop2 } = this.props

    // Render anything
  }
}

export default HomeContainer

First, I import React, some people use destructuring to import Component also, I use the React variable since Component is available as a property of the default export of react.

I also don't use constructor, I prefer to use class properties to define the state, and use the lifecycles of react to fetch initial data or to update state on renders.

I've always though that the use of this in javascript is really hardcore, but I liked though, seems to me like if you had all the javascript wisdom just because .bind is in your code.
I change all of that when working with React, (even tough I still think that using this is cool if that solves your problem) instead of the regular method declaration of the classes I use an arrow function assignment, so this keyword works as expected and looks cleaner.

The first line of the render() method is always the desctructuring of all the props of the component, so next time I come across this component, I know easily which props I'm using without having to dig into all the jsx code (which supposed to be clean).

And last but not least, I export the component at the end of the file.

Functional components

For functional components I follow kinda the same rules:

import React, { useEffect } from 'react'

function HomeContainer(props) {
  const { prop1, prop2 } = props

  // '[]' == no deps == one execution == componentDidMount
  useEffect(() => {
    // Initialization of component's 'state'

  }, []) 

  return (
    // All the render
  )
}

export default HomeContainer

So I still use the same destructuring-first technique for the props.

When I need to do some state initialization of my functional components (i.e using useState hook) I use the useEffect hook, which is the replacement for the lifecycles on the class components.

Finally I export my component at the end of file.

Handle JSX

JSX is the syntax extension for javascript, it looks like html tags, and allows you to manipulate the UI of your components.

There are some rules when using JSX though, one of the most known rule is the use of className instead of class for the html tag property, this is because the special keyword class in Javascript represents a class declaration and it's reserved.

Another special rule for jsx is that it doesn't allow multiple elements to be rendered, something like this:

import React from 'react'

function CheckBox(props) {

  return (
    <label>
      Checkbox
    </label>
    <input type="checkbox" value="1" />
  )
}

This component is not jsx-valid, since you can't render multiple elements from a React component, instead you have to wrap all the content within a parent element. Most people use a div

import React from 'react'

function CheckBox(props) {

  return (
    <div>
      <label>
        Checkbox
      </label>
      <input type="checkbox" value="1" />
    </div>
  )
}

This works perfectly mostly of the time, but there are some special cases where this could be an issue (i.e. inside of a table row, you can't have a div element as a child), so for those cases, the React team
build Fragment.

With Fragment you can safely return multiple elements without worrying about the semantic of the html

import React from 'react'

function CheckBox(props) {

  return (
    <React.Fragment> // <>
      <label>
        Checkbox
      </label>
      <input type="checkbox" value="1" />
    </React.Fragment> // </>
  )
}

There's a shortcut for Fragment that you can use instead: <> ... </> but you have to choose when to use it, since this shortcut doesn't accept any prop while the Fragment component let you use the key prop, which is helpful when creating elements within a loop.

Organize your dependencies

When I started working with javascript, I loved how the community helps to solve any kind of issue. Almost anything you would need when creating an app is likely to have it's own library/sdk than can help you with that.
At first glance, that's good, but it can lead you to a laziness development, where you are used to find a library for nearly any feature you'd need, so when you don't find the library, you start thinking that it might be hard to do (at least that was what I though :sad:).

In order to remove that bad habit of depend a lot of my dependencies (that's what the name stands for ??), I started to take a look to the code that I included on my projects, and that's how I realize that some of it it's really simple that it might wont worth to be included, and can be just a new file in the utils/ folder.

I also try to think twice before install a dependency that's kinda small (I used to include momentjs on each project that I needed to present a simple formatted date) so my node_modules/ folder doesn't grow up too much.

Versioning on your dependencies

Versionin is a huge problem on the Javascript environment (I supposed that all languages have this problem). You install the version 9.x of a dependency, and it works perfectly on your React 16.3, but then after a few months (or even weeks) in production, a new version of that library came out, and you just deploy normally to production, then npm install do it's job. Next, you have a white screen (no matter how many times you reload the page) presented to your users, ugh!!

With npm, you can use Range versions to control the version of your dependencies, by default it's configure to use the caret range, that means patch and minor updates are allowed

^1.0.0 => 1.x.x
~1.0.0 => 1.x.0

So when you install a package, your package json looks pretty much like this:

"dependencies": {
  "react": "^16.3.1",
  "momentjs": "^4.3.1",
  // ...
}

Even though that minor and patch updates should not break your code, not everyone follow that rule, and sometimes you can struggle with that for a long time without notice that it's because of the library version.
That's why I lock the version of my dependencies (I just remove the caret or the tilde), so whenever I do a npm install again, the same version of the dependency will be downloaded.

Of course, doing this will require that you keep up-to-date with the dependencies that are likely to be updated often.

Wire up

One of the reasons why Javascript is well adopted, is the flexibility on how to write code, it doesn't have an explicit convention on how to do it, but that can lead to technical debt when doing it, that's why I stick to some rules when working with Javascript, and also why you should do it too, the future yourself (or any developer you work with), will thank you for that.

I presented you a small style guide (that hopefully will grow with the years) that I follow when working with React, you can use it, or twist at your convenience, whatever makes you feel happy when programming!

Thanks for reading and happy coding!

You really want to be a Senior??

Cristofer — Mon, 11 Feb 2019 17:36:00 +0000

^{^{^{^{^{several-programming-languages. viewed Feb 1 2019, < https://www.kkeducationsociety.org.in/wp-content/uploads/2018/10/Programming-Language.png >}}}}}

Do you want to be a senior?

Nowadays there's several programming languages for any purpose (web, analytics, cloud-computing, IA, ML, etc...), but even in this big 'era' where each week there's a millions of new ways to solve the same issue, there are several people fighting each other to defend his own way to solve the problem.

We all have this "hater" inside of us, we all like our own way to solve the problem (that's why we do it in first place), but why do we try to convince to other people that our way is the best way? Just because it has worked for us? i think this can be pretty selfish thinking

I have learned across all my (little) career that sharing knowledge is the best way how you can actually learn something.

I always thought that a Senior programmer was this mythical men, stackoverflow-less that always have a solution after been staring at the screen with pensive face for like 10 seconds, but now i understand the real importance (i mean besides of all the mythical-men stuff) of this valuable person: MENTORING

Help and let yourself help

All start from the bottom, we all miss the WHERE on the DELETE statement, we all make the same silly mistakes that the people you call "noob" is making now, and just because you understand them now, doesn't mean all the people will magically catch up.

Sometimes can be really annoying having someone right next to you asking you all about the project, but hey! if explain takes you some time, try understand, without any backup, a project that already has thousands of records and millions of lines of code?. Trust me, at the end of the day you'll get payoff with having someone that you can delegate work to

MENTORING === PATIENCE

Everything become easier when you understand it, but you need to be aware, and most important, never forget what it takes you to do it. Each time a person ask you something, is giving you his trust to help him to solve his misunderstanding, it's already shame enough for some people to ask, so there's no need to be rude when you're explaining something.

I know sometimes it can be really hard to be patient (i mean, at the end of the day you're a senior, it's obvious that you have really important things to do), but helping will always be worth it, and you must find a way (normally people can wait) to make this happen.

What is a Senior?

Besides all the normal task of a Senior Programmer, he/she must help younger people to increase their level

What make's a programmer, Senior?

Years of Experience: NO!, i honestly think this is not longer a fair measurement to take in count, i've seen so many people with poor years of experience but a really deep knowledge about what they are doing and vice versa
Solving real hard bugs: is really likely that someone already had the problem you are having now, so is just matter of dig a little bit more to find the solution, although this is a great ability
Not use Google anymore: you have a great memory, but we are talking about knowledge here
Really long beard: Hell no! although sometimes helps (visually 🤪)

It's all about Responsibility.

You need to understand that no one but you is responsible for your own actions, if you make a "quick fix" that introduce technical debt in your code, be responsible when you have to refactor it once you have 10,000 rows inserted on your db per day, the same when you don't explain how to setup the project to the new guy on the team, be responsible when he start to adding all the spaghetti code to the repo.

Once you start taking this with more seriousness, you'll be able to see what you are doing wrong.

Go for it!!

I know all of this might sound really disturbing and we didn't get into this to teach people, but this is a win-win situation, and it actually works, you can see it all everywhere, communities, workshops, etc... they all share the same philosophy: Share and Grow

So, do you still want to become a Senior?