DEV Community: David Rodríguez

Learning React (I): Three HelloWorld examples

David Rodríguez — Tue, 03 May 2022 18:23:36 +0000

Header Image from Unsplash, user Markus Spiske, @markusspiske.

Table of Contents

Introduction.
Hello World using a single HTML file.
Hello World splitting files.
Hello World building a local environment.
Read More.

1. Introduction

React or React.js is one of the most popular resources for creation of Interfaces based in JavaScript, for SPA (Single Page Application), PWA (Progressive Web Application) or maybe “Isomorphic JavaScript” (that is, the execution part in server and part in client). React was created by Facebook and Open-sourcered in 2013, available since then from repositories and libraries that can be fully integrated into your project.

In my case, I haven't used React until recently and due to the needs of a project: I'm working with decoupled Drupal models (headless) and the frontend had been created with React. I had used Angular for some pet-projects, so I had some basic SPA concepts already known. But now I'm working with React and I wanted to share some basic steps that can be executed to better understand some fundamental React concepts.

I thought I'd put together some examples in a progressive way, from less to more, in a series of articles focused on working with React as a frontend technology on a daily basis. So please, read, share and take advantage of everything you can find useful.

2. Hello World using a single HTML file

Our first example is the most basic case that you can implement in your own environment without any configuration or package manager. It only requires a single HTML file, a browser to open the HTML file and some external links to get the React resources.

How does it work? Well in order to create a new basic React example we only need some basic resources:

The basic React Library: The essential JavaScript library for building user interfaces.
The basic React Dom Library: A package that provides DOM specific methods and resources.
The Babel Tool: Babel is a compiler / transpiler that converts code to compatible versions. Also works with React and its native syntax, JSX. You write code in JSX and Babel will convert your code into usable JavaScript. That’s all.

Firstly, we’ll create a new single and basic HTML file, called react_hello_world.html with an basic scheme of HTML tags inside, something like:

<!doctype html>
  <html>
     <head>
           <title>My custom title</title>
     </head>
      <body>
         <p>Hello World!</p>
      </body>  
  </html>

Not difficult, right? This kind of file can be created in your favorite text editor or in your selected IDE. And then you’ll only need to open the file with your browser and see the Hello World message in screen:

Remember: If you don't understand the above lines very well, it might be interesting for you to know the basics of HTML.

Secondly, We’ll add the external React resources, by using the common HTML tag <script>. Doing so we’ll requesting all the necessary tooling: React (basic), React Dom (to operate with DOM in HTML) and Babel (the Compiler / Transpiler for JSX, the React syntax). We’ll include the new links in our <body> section:

<!-- Load React basic resources. -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/15.4.2/react.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/15.4.2/react-dom.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/babel-standalone/6.21.1/babel.min.js"></script>

Lastly, We’ll create a new <div> tag which will be just like our new “entry point” for the new React component: we’ll hook our custom element from this item, and we will call it “root” inside the <body> section as well:

<div id="root"></div>

And now we have to add the code of our new custom React Component, our salutation. We can see the next three parts in the snippet below:

<!-- Loading our new React component. -->
<script type="text/babel">
  <!-- 1- Description. -->
   class Greeting extends React.Component {
     render() {
  <!-- 2- Message to render. -->
       return (<p>This is a greeting generated from a unique               HTML local file!</p>);
     }
   }
  <!-- 3- Render Instructions. -->
  ReactDOM.render(
    <Greeting />,
      document.getElementById('root')
  );
</script>

The Description: We’ve created a class extending React.Component.
The Message to render: We’ve added a string within a return function.
The Render instructions: We’ve used the ReactDOM library in order to launch the render of our new component/class, hooking the new item inside the id=”root” created <div> tag.

Finally, our HTML file will look:

<!doctype html>
  <html>
     <head>
       <title>Document title</title>
     </head>
     <body>
       <p>Hello World!</p>
       <div id="root"></div>
       <!-- Load React. -->
       <script src="https://cdnjs.cloudflare.com/ajax/libs/react/15.4.2/react.js"></script>
       <script src="https://cdnjs.cloudflare.com/ajax/libs/react/15.4.2/react-dom.js"></script>
       <script src="https://cdnjs.cloudflare.com/ajax/libs/babel-standalone/6.21.1/babel.min.js"></script>

       <!-- Load our React component. -->
      <script type="text/babel">
         class Greeting extends React.Component {
           render() {
             return (<p>This is a greeting generated from a unique HTML local file!</p>);
         }
       }

       ReactDOM.render(
       <Greeting />,
       document.getElementById('root')
       );
     </script>  

    </body>  
</html>

We’ve already finished! We are done! remember these three basic steps we have done (it will be the core of any basic development with React): we have created a class/component, we have asked it to render and we have indicated from which element of the DOM (HTML) we wanted to load the new component. That's all!

And now if you open the file with your browser using right click from mouse or line command (you can use $ xdg-open react_hello_world.html ) you’ll see the new version of our Greetings file:

3. Hello World splitting files

We have now created our first "Hello World" with React in a unified way, in a single file, loading the external resources and generating an output to a "root" element. But this is not usually the daily reality, where we work with separate files of a different nature.

To make this approach more "real", we are going to use a simple and intuitive platform that allows us to start separating resources. We will try with CodePen.io, an online platform for testing code snippets especially focused on HTML / CSS / JavaScript for web.

Enable an account and create a new snippet / pen. Then we only have to set some basic configurations in our new snippet / pen: select Babel as JavaScript Preprocessor (remember we’re using JSX syntax and It’s not pure JavaScript) and add external scripting for the basic react library and the react-dom library (as in the previous example).

CodePen will load the scripts in our code before rendering the snippet. There we go.

Firstly, in the HTML tab we’ll include a basic original <div> working as root element for our React example:

<div id="root"></div>

Secondly, we’ll build the JSX snippet in the JS tab. In this case, we’re using latest versions of React and as you can see, we have some differences with respect to the first example in this post. Let’s see the code:

const container = document.getElementById('root');
const root = ReactDOM.createRoot(container);

class Button extends React.Component {
  render() {
    return (<div className="button">Hello World! this is a greeting generated from different files.</div>);
 }
}
root.render(<Button />);

What’s happening here? Well, now we’re using ReactDOM.createRoot instead of ReactDOM.render (as in the first case), due to changes in ReactDOM versions. This is something that has changed in the latest versions: ReactDOM.render is no longer supported in React 18, but I have kept the two different examples for different versions of React (15.x vs 18.x). You can read more info about it here:

Finally, we’ll add some (very basic) styles in order to see the rendering. We’ve add some colors to the specific <div> and the message in screen:

.button {
  padding: 40px;
  color: red;
  background: black;
}

The three tabs will load a React example using a Hello World message in our CodePen board, showing in console the internal structure:

4. Hello World building a local environment

Well, ok. We’ve built a first example using an unique HTML file, then we’ve built another Hello World example using separate files in an external environment (CodePen.io) and now we have to take another step: We are going to build a new example from a local environment, which involves the initial and basic installation and configuration of a local development environment for React.

This is really the interesting part of this block: What do we need to work locally with React? Let's see.

Building up your local environment

1. Install Node.js (Ubuntu)

Node.js is an execution evironment for executing JavaScript from the server side. You will need to enable Node in your environment in order to work with React. In Ubuntu, you can install Node.js just by command line from the official repositories, by doing:

$ sudo apt update
$ $ sudo apt upgrade -y
$ sudo apt install nodejs -y

But it can install an older version of Node.js… so we’ll need to execute an update..

2. Install NPM // Update NPM (if needed) // Or install Yarn

We’ll need a package manager in order to resolve dependencies, so we can use npm and yarn (npm-compatible). Using npm we’ll be able to update the current Node.js version to the latest stable version or non-stable.

$ sudo apt install npm
$ sudo n latest

For updating npm as package manager, you can run:

$ sudo npm install -g npm

This will install or just will update your current npm version and resources:

Yarn is another JavaScript package manager and is compatible with npm. It helps us automatize installing, updating, configuring, and removing npm packages, speeding up the installation process.

$ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
$ echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
$ sudo apt install --no-install-recommends yarn

$ yarn --version
1.22.18

3. Install // Use create-react-app tool

Create React App is a very-comfortable tool for creating new apps based in React in your local environment. It works on macOS, Windows and Linux and you don’t need to install and configure resources as Babel or webpack: they are preconfigured! You’ll need to have Node >= 14.0.0 and npm >= 5.6 in your environment.

We can install create-react-app as a new dependency by using npm:

$ sudo npm install -g create-react-app

This command will install the package as a global resource with -g flag. This will do:

$ create-react-app --version
  5.0.1

And this will be ok and can be used for initial testing, but its creators recommend us to uninstall the global resource in order to force that we’ll use the latest version of create-react-app per specific project, just like a dependency. So use the next two versions:

$ npm uninstall -g create-react-app
[...]
$ yarn global remove create-react-app

Creating the component

Now we’re going to create our first Hello World React app in a local environment using scaffolding generated by the create-react-app package. And we’ll also use npx. npx is a package runner tool that comes with npm.

$ npx create-react-app hello-world
$ cd hello-world
$ npm start

But you can use alternatives like npm or yarn:

$ npm init react-app hello-world-2
$ cd hello-world-2
$ npm start
[...] 
$ yarn create react-app hello-world-3
$ cd hello-world-3
$ yarn start

The fact is that after launching the start, the new application will be launched via the pre-configured web server and the application will be deployed directly through port 3000 (be careful if you have it in use), opening from your favorite browser:

Now we have a new React App created with scaffolding. …But what do we have inside?

Inspecting the rendered component

And at the end, we can open the just created folder with our new React App “Hello World” and see how the scaffolding provided by create-react-app is. Open now the created folder in your favorite IDE // Editor and see the content within the project:

Here you can see all the dependencies downloaded (folder “node_modules”), the public folder with all the resources for the web server, the src folder with the code of our app and other files like a basic gitignore (create-react-app starts git as control version system in the new folder) and the files for registering dependencies (package-lock.json and package.json). Among all these resources, there some important files that we’ve to review:

index.html: The HTML main file, with a div called “root” as entrypoint for our app.
App.js: Our new component, described in JSX syntax and with a central message for screen.
index.js: The file loading the App component and charging the rendering from the root div present in index.html file.

We’ll change the central message placed in App.js and we’ll put this:

<p>Hello World! this is a React App from a local environment.</p>

Now just saving the change and reloading the URL in browser you’ll see our custom updated message. That's all! We’ve done it!

To conclude, we need to review all the little things we have practiced throughout this article on getting started with React. We wanted to create "Hello World" cases and almost without realizing it, we got a great snapshot (the big picture) of the fundamentals of React.

You can download the last two examples of this post from the Github repository: use the single HTML file and for the React local App, just run $ npm install (this will download all the node_modules folder for dependencies) and then $ npm start in order to run and launch the App in server + browser.

What do we know now?

The most basic resources for developing React App: The react library, the react-dom library and the Babel Transpiler (remember you’re using JSX syntax).
Basic resources for developing React code in a local environment and how to install and use it:
- Environment: Node.js
- Package Managers: npm, yarn
- Command Runner: npx
- Package for basic React Apps: create-react-app
Scaffolding of basic React Apps using create-react-app

5. Read More

Erasing traces of Generator in Drupal Projects

David Rodríguez — Fri, 01 May 2020 18:21:04 +0000

Image from Unsplash, user Kim Gorga, @kimgorga

1-Introduction

It's very common, when you're working on projects, to receive a ticket from the client requesting the removal of signals that make it easier to know with which technology the website has been generated.

Normally, the client performs a security audit to the platform and from there several frequent items are generated: update the core to keep up to date in security, Normally, the client performs a security audit to the platform and from there several frequent items are generated: updating the core to keep up to date in security (being aligned with https://www.drupal.org/security in core and patches), as well as some common places, which often go through hiding sensitive information to possible attackers.

2-Premise

Okay, but are there ways to completely hide the fact that the website was built using Drupal?
Well, no. In fact, anyone can open the code inspector console of a decent browser (Chrome, Firefox) and when in doubt as to whether they are looking at a Drupal-based site, call up the Drupal JavaScript object. And it will always respond with its associated properties and methods:

And usually a quick scan of their associated JavaScript libraries will reveal names like drupal.js, which makes it difficult to hide the technology (sometimes we even get the request to rename these JavaScript libraries to hide the keyword 'drupal'...).

Having explained this, it is true that we cannot hide the generator from a human eye, but perhaps we can help hide it (on a basic level) from the machines. Some tactics even include offering an adulterated robots.txt structure to simulate another technology and make crawlers believe that it's another platform (WordPress for example), and building a honeypots subsystem internal to the spoofed addresses to detect spying... but I think that's already another topic for another article.

3-Targets

Here (having stated this former important premise) I would just like to collect some solutions to hide meta-information in some parts of the Drupal installation when you wanna obfuscate that you are running a Drupal installation:

1- First of all: hide the "Generator" meta tag from the 'head' section of a document - page delivered to the web browser:

2- Then: I would also like to remove from the server -> client response headers a specific Drupal header called X-Generator, which delivers the server version of Drupal:

X-Generator is created in Drupal installations and fullfilled with info about the system version (xhr is a shortened way for XMLHttpRequest).

The tag is setted from the class ResponseGeneratorSubscriber present in the Core of Drupal:

Is managed through an onRespond() function that follows the Drupal event subscription pattern (itself based on Symfony event management):

  /**
   * Sets extra X-Generator header on successful responses.
   *
   * @param \Symfony\Component\HttpKernel\Event\FilterResponseEvent $event
   *   The event to process.
   */
  public function onRespond(FilterResponseEvent $event) {
    if (!$event->isMasterRequest()) {
      return;
    }

    $response = $event->getResponse();

    // Set the generator in the HTTP header.
    list($version) = explode('.', \Drupal::VERSION, 2);
    $response->headers->set('X-Generator', 'Drupal ' . $version . ' (https://www.drupal.org)');
  }

4- Tasks

To make the hides of the information shown in the previous section, we will use a combined action of the paradigms that currently exist within Drupal: the procedural of the Hooks system (vestigial) and the OOP of the event subscription systems. We are going to use both techniques in a combined way.

4.1- Building a custom module

We're going to create a new custom module for our goals, I will call it "headers_manager" -in a clear show of creativity, of course- and I will create the basic resource:

headers_manager
   \_headers_manager.info.yml

And as info:

name: Headers Manager
description: Custom Module created to manage meta-info from head and headers.
package: 'Workshop Drupal'
type: module
core: 8.x

4.2- Building a Hook

Next, we're going to work over the metatags in the

section of the HTML content, for wich we'll need a Drupal Hook, something called hook_page_attachments_alter, just a procedural function to change assets to a page before the rendering phase.

According to its own documentation:

Use this hook when you want to remove or alter attachments on the page, or add attachments to the page that depend on another module's attachments (this hook runs after hook_page_attachments().

So we're going to use the hook within a .module file. In the hook only we'll review the html_head charged as attachment to every page sended to render. And if the keyname of the attachment is equals to the meta tag that we're looking for, then we'll unset the value.

/**
 * Implements hook_page_attachements_alter().
 * @param array $attachments
 */
function headers_manager_page_attachments_alter(array &$attachments) {
    foreach ($attachments['#attached']['html_head'] as $key => $attachment) {
        if ($attachment[1] == 'system_meta_generator') {
                unset($attachments['#attached']['html_head'][$key]);
        }
    }
}

Now our custom module has:

headers_manager
  \_headers_manager.module
   \_headers_manager.info.yml

4.3- Building an Event Subscriber

The nex step is disable the X-Generator header in responses from the Server. For this, we'll build a new EventSubscriber as in the original case where the header is attached (has been seen before).

First, we're creating a new service for our Subscribe in a .service.yml file:

services:
  headers_manager_response_header:
    class: Drupal\headers_manager\EventSubscriber\HeadersManagerResponseSubscriber
    tags:
      - { name: event_subscriber }

Then, we'll create the Subscriber using a path like headers_manager/src/EventSubscriber/HeadersManagerResponseSubscriber.php.
In our new Subscriber class file:

<?php

namespace Drupal\headers_manager\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\FilterResponseEvent;
use Symfony\Component\HttpKernel\KernelEvents;

/**
 * Response subscriber to remove thes X-Generator header tag.
 */
class HeadersManagerResponseSubscriber implements EventSubscriberInterface {

  /**
   * Remove extra X-Generator header on successful responses.
   *
   * @param \Symfony\Component\HttpKernel\Event\FilterResponseEvent $event
   *   The event to process.
   */
  public function HeadersManagerOptions(FilterResponseEvent $event) {
    $response = $event->getResponse();
    $response->headers->remove('X-Generator');
   }

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents() {
    $events[KernelEvents::RESPONSE][] = ['HeadersManagerOptions', -10];
    return $events;
    }

}

So we'll capture events from the Kernel, and specifically we are asking for the event RESPONSE, assigning it in an array the name of the function that is responsible for interacting with the event, and a figure that represents the 'weight' as an order of priority of execution of our event alteration. Thus with a low weight, we ensure that our alteration is executed just after the attachment of X-Generator in the previous subscriber. Using a low value we avoid that our change is executed before the loading of the header.

Finally our module will have the internal structure:

headers_manager
  \_headers_manager.info.yml
   \_headers_manager.module
    \_headers_manager.services.yml
     \_src
         \_EventSubscriber
             \_HeadersManagerResponseSubscriber.php

And so with this custom module, after enabling it in our Drupal installation, it will process the pages delivered by the server from the hook and from the event subscriber to remove the information we have configured.

You can download the custom module here, from my Gitlab profile.

Managing configuration objects in Drupal 8|9 for Migrations

David Rodríguez — Wed, 08 Apr 2020 01:54:42 +0000

Image from Unsplash, user Denis Chick, @drc1948

Introduction

Well, I was working in some migrations and I thought that it would be interesting to gather some tools for working with configuration objects, especially from the point of view of Drupal migrations based on a treatment as configuration (not as code).

You can learn the differences between both approaches (Migration as code or Migration as configuration) in this article: https://www.therussianlullaby.com/blog/thinking-about-drupal-migrations-examples.

But maybe the most important point right now it's that if you decide to manage a Drupal Migration as a Configuration entity, then, you'll create a new active configuration Object in your Drupal Installation. This change all the whole workflow of a single migration as code, due to (now), you're putting your new migration inside the processes and workflows of the Configuration Management System of Drupal. Ok? Let's see.

I'm working in a basic migration example using a classical .csv file as datasource. I'm building the basic scaffolding in a custom module, with the next structure:

/project/web/modules/custom/  
                     \__migration_csv_module/  
                         \__migration_csv_module.info.yml
                          \__csv/
                               \_migration_csv_articles.csv
                           \__config/
                              \__install/
                                 \__migrate_plus.migration.csv_import.yml

In order to run the migration using drush commands for migrations, First I will have to load the new active configuration object. Ok.

You can use the User Interface in path:
/admin/config/development/configuration/single/export

And finally, if I decide stop the migration and delete the results, I have to eliminate this config object. Let's see some tactics.

Auto delete the active config object

When you're working with Drupal migrations as config, then you have to ensure the delete of the new migration-related config object in your Drupal System. You have to declare your own custom module as a forced dependency of the migration, and so when you disabled the module, then this config object will disappear.

I mean: file migrate_plus.migration.article_csv_import.yml

with content:

uuid: 1bcec3e7-0a49-4473-87a2-6dca09b91aba
id: article_csv_import
label: 'Migrating articles'
langcode: en
status: true
dependencies:
  enforced:
    module:
      - migration_csv_module

Reviewing configuration objects

You can use this contrib module in order to test and review config:

Configuration Inspector Module.

I didn't know it, but in the context of this issue, Pedro Cambra recommended me to use it. With this module you'll can review a config:

Deleting configuration objects

Also you can use the classical tools from drush and drupal console (both are Drupal CLIs) in order to delete some config objects.

Using drush

:~$ drush config-delete 'migrate_plus.migration.csv_import'

:~$ drush config:delete "migrate_plus.migration.csv_import"

:~$ drush cdel migrate_plus.migration.csv_import

Using Drupal Console

:~$ drupal config:delete active "mymigration.active_config_object"

:~$ drupal cd active mymigration.active_config_object

You can use this contrib module from Goran Nikolovski:

Config Delete Module.

Just install this module and visit the following page:

/admin/config/development/configuration/delete

Then you'll be able to select the Config Object and delete it.