DEV Community: kaiser shahid

Humane Intro to React (and JSX, and some ES 6)

kaiser shahid — Mon, 03 Jun 2019 19:43:59 +0000

What is React?
The Checkbox-Textbox Example using jQuery
- Conclusion
The Checkbox-Textbox Example in React
- ES 6 and JSX Quick Primer
- Making Our Component Interactive
- State (this.state)
- Destructuring (ES 6)
- Try it Out
- Arrow Functions (ES 6)
- Try it Out
- Conclusion
- Lifting State Up
Nested Components
- Properties (this.props)
- Using Our New Component
- Communicate with Parent Component (indirectly)
- Conclusion
Wrapping it Up
- How does React do this magic?
- Further Readings
- Next Up

Table of contents generated with markdown-toc

Javascript was the first programming language I learned, sometime around 1998. I've always enjoyed it, but I feel like I had a very early 2000s take on it -- jQuery and MooTools were the popular frameworks. You wrote a lot of your code from scratch, and you walked 5 miles up and down a hill to revert changes.

So, when I dipped my toes into the new world of Node.js and React and npm, I was blown away with both how much easier things got and, ironically, how much more complicated the ecosystem and tooling became.

It took someone explaining it to me in person, and working through my questions, for me to start understanding what React was. Maybe I'm a bit dense here, but the documentation I've come across didn't make sense until another person explained it.

There might not be any getting around it ultimately, but, I'm going to try to explain React as humanely as possible so you can get a sense of it organically. You should already be familiar with Javascript and HTML. Rather than having you setup a local environment and all that, I'll post live examples on jsfiddle.

Let's get going.

What is React?

React is a UI framework created by Facebook. It works well with a design pattern called flux (also Facebook).

The goal is to have a simple, one-way flow of connecting the UI to data and user input. No more having to markup HTML with onEvent handlers and separately writing a bunch of jQuery with complex relationships.

By one-way, take the basic structure of <a><b>text</b></a>. We can write this relation as a -> b. Any change to a forces both a and b to re-render, while any change to b only re-renders it. b knows nothing about a.

I'm not going to start with React, though.

The Checkbox-Textbox Example using jQuery

Let's say we have a checkbox where we can enter an expiration date, but we need to explicitly enable it with a checkbox. If the checkbox is unchecked, the field should be blank and disabled. Like this:

<form id='example-01'>
<input type="checkbox" name="enableExpiration" />
<input type="text" name="expirationDate" disabled />
</form>

I'm going to write this using jQuery:

var textbox = $("#example-01 input[name='expirateDate']");
var checkbox = $("#example-01 input[name='enableExpiration']");
checkbox.on('click', function(event) {
   if (event.currentTarget.checked) {
       textbox.prop('disabled', false);
   } else {
       textbox.val('').prop('disabled', 'disabled');
   }
});

See jsfiddle

Pretty simple. Now let's add some validation -- if the date isn't correct (let's say it's alphanumeric characters only) when you change focus, show a red error box under the controls. Now our HTML might look like this:

<form id='example-02'>
<input type="checkbox" name="enableExpiration" />
<input type="text" name="expirationDate" disabled />
<div class="errorMessage" style="display: none; background: red; color: white">
</div>
</form>

And our Javascript would look like this:

var textbox = $("#example-02 input[name='expirateDate']");
var checkbox = $("#example-02 input[name='enableExpiration']");
var errorMessage = $("#example-02 .errorMessage");

checkbox.on('click', function(event) {
   if (event.currentTarget.checked) {
       textbox.prop('disabled', false);
   } else {
       textbox.val('').prop('disabled', true);
   }
});

textbox.on('blur', function(event) {
    console.log('blur');
    if (!textbox.val().match(/^[\w]+$/)) {
        errorMessage.show().html('Invalid date!');
    } else {
        errorMessage.hide();
    }
}).on('focus', function(event) {
    errorMessage.hide();
});

See jsfiddle

Conclusion

Our current relationships look like this:

Checkbox -> Textbox -> ErrorMessage

It alls looks ok and manageable so far. But as your needs start to grow, this
can start to get out of hand pretty quickly. There's also a lot of boilerplate code. And what happens when you want to re-use this field in other places?

Let's go a step further and pretend we already have a systematic way to manage these sets of fields and create different instances. Is that something we can easily apply to new fields?

The Checkbox-Textbox Example in React

First, let's imagine our checkbox-textbox-error combo from before as a single field called Optional Expiration Date. We could write some JS like this:

// OptionalExpirationDate.js
import React from 'react';

class OptionalExpirationDate extends React.Component {
    render() {
        return <div className="optional-expiration-date">hello</div>;
    }
}

export default OptionalExpirationDate;

If you've never seen ES 6 or JSX, this will look pretty magical. (It still kinda is for me.)

ES 6 and JSX Quick Primer

I'll do a quick breakdown of the code:

import React from 'react';

This loads the React object from the library 'react'. You need it anywhere you use the JSX syntax.

class OptionalExpirationDate extends React.Component {

React.Component is the backbone of what powers React. Our class can now be rendered.

render() { return <div className="optional-expiration-date">hello</div>; }

All React components need a render() method. It returns JSX, which is a hybrid HTML-Javascript syntax. We're returning the equivalent of <div class="optional-expiration-date">hello</div>

export default OptionalExpirationDate;

This means when where we're doing import ClassName from 'OptionalExpirationDate.js';, the OptionalExpirationDate class is what's returned. There are other ways to import and export.

Now, in another file that initializes the page, we could have:

// boot.html
<div id="example-03"></div>

<script type="javascript">
import OptionalExpirationDate from 'OptionalExpirationDate.js';

let opt = <OptionalExpirationDate />;
ReactDOM.render(opt, document.getElementById('example-03'));
</script>

See jsfiddle (code has been changed slightly to work in jsfiddle)

So, when the page renders you'll see <div className="optional-expiration-date">hello</div> within #example-03. Let's expand our component:

// OptionalExpirationDate.js
import React from 'react';

class OptionalExpirationDate extends React.Component {
    render() {
        return <div className="optional-expiration-date">
            <input type="checkbox" name="enableExpiration" />
            <input type="text" name="expirationDate" disabled />
            <div className="errorMessage" style={{display: 'none', background: 'red', color: 'white'}}></div>
        </div>;
    }
}

export default OptionalExpirationDate;

See jsfiddle

It's almost the same as our initial HTML except for some key things in JSX:

since class is a reserved word, we have to use className
styles are expected to be key-value pairs as a JS object. Without quoting, attributes like font-size become fontSize
style value is enclosed with {} -- this means to use JS code instead of a literal value. This opens up a world of possibilities

Making Our Component Interactive

So far everything should've been straightforward. We've only focused on outputting HTML. Now let's do some wiring. We're going to introduce three new things that plunge us into the React world, and this section is going to be long (sorry):

state (React's way of tracking changes in the UI)
destructuring (set local variables to/from an object)
arrow functions (compact inline functions)

// OptionalExpirationDate.js
import React from 'react';

class OptionalExpirationDate extends React.Component {
    state = {inputChecked: false, errorMessage: null};

    toggleCheckbox() {
        this.setState({...this.state, inputChecked: !this.state.inputChecked});
        return this;
    }

    setErrorMessage(msg) {
        this.setState({...this.state, errorMessage: msg});
        return this;
    }

    render() {
        return <div className="optional-expiration-date">
            <input type="checkbox" name="enableExpiration" onClick={() => this.toggleCheckbox()} />
            <input type="text" name="expirationDate"
                disabled={this.state.inputChecked ? false : true} />
            <div className="errorMessage"
                style={{
                    display: this.state.errorMessage == null ? 'none' : 'block',
                    background: 'red', color: 'white'
                }}>{this.state.errorMessage}</div>
        </div>;
    }
}

Reading through it, it should still make sense at a high level. And look, all the functionality is sitting close with the HTML! Do you see any selectors being used? Are we even directly referencing an HTML element here? (Nope and nope.)

How is this possible?

See jsfiddle

State (`this.state`)

The first thing to explain is state. Notice we have toggleCheckbox() and setErrorMessage() both call setState({...}). When this happens, React knows to reprocess this component (and in effect, all its children). This is essentially the core of the React/flux pattern.

Destructuring (ES 6)

The second thing to explain is destructuring. Let's say you have an object:

let map = {a: 1, b: 2};

If we want to merge this with another object, there are a bunch of ways to do this in old JS. We'll go with a manual approach:

let mapNew = {a: map.a, b: map.b, c: 3};

With destructuring, the following is equivalent:

let mapNew = {...map, c: 3};

The ...map is essentially copy every key-value from map when it's on the right side.

Another way destructuring is frequently used is as follows:

let map = {a: 1, b: 2};
let mapNew = {...maps, c: 3, d: 4};
let {a, b, ...rest} = mapNew;

The last line is equivalent to:

let a = mapNew.a, b = mapNew.b, rest = {c: mapNew.c, d: mapNew.d};

The ...rest means copy all the remaining key-value pairs into rest when it's on the left side.

The final way to use destructuring is to copy local variables into key-value pairs:

let a = 1, b = 2, c = 3, d = 4;
let map = {a, b};
let mapNew = {...map, c, d};

// equivalent to
let map = {a: a, b: b};
let mapNew = {a: map.a, b: map.b, c: c, d: d};

Try it Out

Copy & paste the following into your browser dev console:

let a = 1, b = 2;
let map = {a, b};
console.log('a, b to map', map);

let map2 = {...map, c: 3, d: 4};
console.log('map2 merged with map + {c:3,d:4}', map2);

let {c, d} = map2;
console.log('c, d extracted from map2', c, d);

Arrow Functions (ES 6)

The third thing to explain is arrow functions. You see it in onClick={() => this.toggleCheckbox()}.

This is similar to onClick={function() { this.toggleCheckbox(); }} but not the same. With the function() { } syntax, this isn't actually bound to anything. To make that work in this context, you'd actually have to do the following:

// in render()
const me = this;
return <div className="optional-expiration-date">
    <input type="checkbox" name="enableExpiration" onClick={function() {me.toggleCheckbox();}} />
    ...
</div>;

With arrow functions, this is the object the enclosing method is bound to. That's advantage #1 (and the biggest advantage, honestly).

If you're writing a one-liner, () => statement executes the statement and returns the value. For multiple statements (or if you want to be more verbose), you'd write () => { return statement; }. If you had a single argument, you could write (arg) => statement or arg => statement. That's advantage #2.

Try it Out

Copy & paste the following into your browser dev console:

const f1 = () => console.log('called f1');
const f2 = (a, b) => console.log('called f2', a, b);
const f3 = (a, b) => {
    const c = a + b;
    console.log('called f3', a, '+', b, '=', c);
}

f1();
f2(1, 2);
f3(1, 2);

class Throwaway {
    constructor() {
        this.a = '#instance property a';
    }

    getFunc() {
        return () => this.a;
    }
}

let t = new Throwaway();
let callback = t.getFunc();
console.log('retrieving t.a from an arrow function callback', callback());

Conclusion

Our initial HTML/jQuery field has become a single unit now encapsulated by one class. The code is line-for-line longer, but look at what happens:

we don't have to write/track messy CSS selectors
we treat HTML as an object, which directly ties the functionality with the context
everything is acting as a logical unit

So, less codesoup. (At least in this example. The rest of the React world isn't perfect.)

Here's our relationships now:

OptionalExpirationDate
 └-> Checkbox
 └-> Textbox
 └-> ErrorMessage

Lifting State Up

Another thing that happened in our component is that the sibling components don't know anything about each other. It's the task of the parent component to figure out what to pass on to the children. This also reduces complexity. This, at its simplest, is what's called lifting state up. Understanding this will make React code easier to work with.

With this baseline understanding, let's finally add validation to our React example.

Nested Components

We haven't worked with nested component yet. In fact, anything in the form <lowercase ...> is always treated as final HTML output. So, let's make the error message box its own component. We should be able to pass it a message that's either a string or null -- if it's null, it should be hidden.

// in ErrorMessage.js
import React from 'react';

class ErrorMessage extends React.Component {
    render() {
        const {message} = this.props;
        const styles = {
            display: message == null ? 'none' : 'block',
            background:'red',
            color: 'white'
        };
        return <div className="errorMessage" style={styles}>{message}</div>
    }
}

export default ErrorMessage;

What's this.props???

Properties (`this.props`)

We've seen the JSX <element key={value} key2="value" ... />. When element is a component, these get converted to the object {key: value, key2: 'value', ...} which gets set on the props property of a React.Component. The default constructor, in fact, is construct(props).

In ErrorMessage.render(), we're extracting the message property from this.props.

Unlike this.state, we never directly change this.props. Think of it as the baseline rules that define how a component should behave, along with any rules/values/etc. that should be passed along to children (more on that later).

Using Our New Component

We're simply going to import ErrorMessage and swap it in for our old <div>:

// OptionalExpirationDate.js
import React from 'react';
import ErrorMessage from './ErrorMessage';

class OptionalExpirationDate extends React.Component {
    state = {inputChecked: false, errorMessage: null};

    toggleCheckbox() {
        this.setState({...this.state, inputChecked: !this.state.inputChecked});
        return this;
    }

    setErrorMessage(msg) {
        this.setState({...this.state, errorMessage: msg});
        return this;
    }

    render() {
        return <div className="optional-expiration-date">
            <input type="checkbox" name="enableExpiration" onClick={() => this.toggleCheckbox()} />
            <input type="text" name="expirationDate"
                disabled={this.state.inputChecked ? false : true} />
            <ErrorMessage message={this.state.errorMessage} />
        </div>;
    }
}

Pretty nifty, right? Let's do our final bit: adding validation.

Communicate with Parent Component (indirectly)

For this, we're going to make another component for the textbox, and we'll expect two properties:

validationCallback should be a callback function to invoke when there's an error. It should take a single parameter message
disabled should be a boolean to enable or disable the field

// Textbox.js
import React from 'react';

class Textbox extends React.Component {
    validate(event) {
        const callback = this.props.validationCallback || (() => {});
        if (!event.currentTarget.value.match(/^\w+$/)) {
            callback('Invalid date: ' + event.currentTarget.value);
        }
    }

    render() {
        return <input type="text" name="expirationDate" disabled={this.props.disabled ? true : false}
            onBlur={(event) => this.validate(event)} />
    }
}

Now, our primary component will look like this:

// OptionalExpirationDate.js
import React from 'react';
import ErrorMessage from './ErrorMessage';
import Textbox from './Textbox';

class OptionalExpirationDate extends React.Component {
    state = {inputChecked: false, errorMessage: null};

    toggleCheckbox() {
        this.setState({...this.state, inputChecked: !this.state.inputChecked});
        return this;
    }

    setErrorMessage(msg) {
        this.setState({...this.state, errorMessage: msg});
        return this;
    }

    render() {
        return <div className="optional-expiration-date">
            <input type="checkbox" name="enableExpiration" onClick={() => this.toggleCheckbox()} />
            <Textbox validationCallback={(message) => this.setErrorMessage(message)} disabled={!this.state.inputChecked} />
            <ErrorMessage message={this.state.errorMessage} />
        </div>;
    }
}

See jsfiddle

So what's happening here? We're passing an inline function (message) => this.setErrorMessage(message) that's bound to the current OptionalExpirationDate component. When ExpirationDate sees a non-null value for its validationCallback property, it uses it to communicate a validation error.

However, it doesn't know what it's communicating with! All it cares about is that there's a callback -- what happens next is not its concern. This is what I mean by indirectly communicating with the parent. And, it still doesn't know the state of its siblings.

Conclusion

Now we've got a React example that's similar to our jQuery example, but we're still not dealing with any selectors, and every individual field still doesn't need to worry about any of its siblings.

Taking a step back, we can now drop this field in wherever we want and it'll automatically work!

const form = <form>
    <OptionalExpirationDate />
    <OptionalExpirationDate />
</form>

Too simple. Of course, we would now need to be able to control the field names so that one date doesn't overwrite the other. What do you think needs to be done?

Solution Spoiler

pass in expirationName to OptionalExpirationDate: <OptionalExpirationDate expirationName="newField" />
pass down name to ExpirationDate: <ExpirationDate name={this.props.expirationName} ... />
in date component, use passed-in name or a default: <input name={this.props.name || 'expirationDate'} ... />

See jsfiddle

Wrapping it Up

Hopefully this has demonstrated, in an easy-to-understand way, some of the core concepts of what React is/does:

Create one direction of data flow so that each component only needs to know about itself and setup its children
Build components to be reusable and customizable with little effort

How does React do this magic?

I've punted on how this all works until now because I didn't want you to get lost in details before you even got to what React is. I'm still not going to do this process justice, but here's a brief overview:

First is JSX. This is a language extension to Javascript. It's not a standard (yet). So how does it work?

React apps are compiled using npm or yarn (or some other build tool). Part of the compilation process involves a library called babel, which scans the files being imported and carries out transformations where it needs to. As mentioned before, whenever we have JSX we always need to have import React from 'react'; in our file. This signals to babel to treat this file as having JSX. So <SomeComponent prop1="whatever" ... /> gets translated to:

let someComponent = React.createElement(
    'tagName',
    {prop1: "whatever", ...},
    [...children...]
);

Now, if you start poking around at other React libs, you'll quickly find that they are written in all sorts of JS variants. But what ties it all together is transpiling -- converting code from one language (or variant) to another. This is what also makes cutting-edge JS syntax available on browsers.

Next is React itself. How does it connect to the actual DOM? React maintains a virtual DOM. Each component you create/inject becomes part of this virtual DOM. When you call setState(), it only affects the component that's called. This in turn updates the virtual DOM, which then renders new HTML in the browser DOM. Remember ReactDOM.render() above? This is what connects the virtual DOM to the browser DOM.

Next Up

We're only scratching the surface here. In the next installment, we'll go a bit deeper with props, state, child components, and higher order components (HOC). And in another installment, we'll actually talk about data flowing into and out of components.

Hope you enjoyed! Please let me know if there are areas I can improve, or if I've totally miscommunicated a concept! Smash that like button and subscribe.

Codecept For Dummies: Part 2: Concepts

kaiser shahid — Wed, 21 Mar 2018 20:36:40 +0000

Codecept For Dummies: Part 1: Overview

kaiser shahid ・ Mar 21 '18

#php #testing #codecept

I went over test basics and how to setup an empty Codecept project (for lack of a better term).

Now I'm going to talk about Codecept's approach to testing. Understanding this will be the key to structuring your actual tests.

Actors (Unit, Functional, Paid Soros Thugs, Whatever)

Tests are executed through the perspective of an actor. An actor has certain expectations:

I want to get the contents of http://www.google.com
I want to verify that there's a search box
I want to check if square(2) == 4

In terms of code, it might actually look like this:

$html = $I->wantContentFromUrl('http://www.google.com')
$I->wantToFindElement("input[title='Search']", $html)
$I->assertEquals(4, square(2), "unexpected value for square(2)");

Each test suite has a unique actor (e.g. FunctionalTester).

Helpers

Helpers are Codecept modules -- they're classes that contain methods that an actor can use. Each test suite can define the helpers that get loaded into an actor.

In practice, Codecept will generate a trait with all the methods from all the enabled helpers, and proxy each method to the class actually implementing it. The actor class then uses that trait.

Cepts

This is the most basic test type. It's basically just a script:

I am on page 'http://www.google.com'
I see element 'input[title="Search"]'
I set value to 'input[title="Search"]', 'kaiser'
I click 'input[value="Google Search"]'
I get sent to 'https://www.google.com/search?q=kaiser'

(BTW, you can actually write Cepts like that.)

In this example, we're making the assumption I am on page saves the HTML somewhere where the other steps can refer to it.

If you need finer control, you can convert that to PHP:

<?php
$I = new AcceptenceTester($scenario);
$I->amOnPage('http://www.google.com');

$searchEle = 'input[title="Search"]';
$I->seeElement($searchEle);
$I->setValueTo($searchEle, 'kaiser');
$I->click('input[value="Google Search"]');
$I->getSentTo('https://www.google.com/search?q=kaiser');
?>
```



For very basic scenarios, write a Cept.

## Cests

If you need to group your steps together for better reusability, write a Cest:



```
<?php
// in file ExampleCest.php

class ExampleCest {
    public function _fetchStep(FunctionalTester $I, $url) {
        $I->startNewSession();
        $I->amOnPage($url);
    }

    public function checkForSearchBox(FunctionalTester $I) {
        $this->_fetchStep($I, 'http://www.google.com');
        $I->seeElement('input[title="Search"]');
    }

    public function doSearch(FunctionalTester $I) {
        $this->_fetchStep($I, 'http://www.google.com');
        $I->setValueTo('input[title="Search"]', 'kaiser shahid');
        $I->click('input[value="Google Search"]');
        $I->getSentTo('https://www.google.com/search?q=kaiser');
    }
}
?>
```



Cests let you collect multiple related scenarios together and allow reuse of common steps. Note that any function starting with `_` is not considered a test, so prefix any methods you don't want to automatically execute.

Cest classes must end in `Cest`, but they can be plain objects by default.

> Note that Codecept does dependency injection for Cests! `FunctionalTester $I` will make Codecept look for `FunctionalTester`, and if found, initialize it before passing it to the method it's about to execute. We'll get more into this in a future article.

## Unit Test

This is what you're probably used to:



```
<?php
// in ExampleTest

class ExampleTest extends \Codeception\Test\Unit {
    public function testScenario1() {
        $this->assertEquals(4, square(2), "unexpected result for square(2)");
    }
}
?>
```



Note that the actor is no longer explicit -- its methods are automatically available to the class (probably through `__call`).

Unit test classes must end in `Test` and extend `\Codeception\Test\Unit`. Test scenarios must start with `test`.

## Conclusion

Each test suite has an actor. The actor uses 1 or more helpers to provide test writers assertions and other methods that are useful for that suite. Tests can be very simple scenarios (Cept), scenarios of varying complexity (Cest), or traditional unit tests.

Codecept For Dummies: Part 1: Overview

kaiser shahid — Wed, 21 Mar 2018 19:08:43 +0000

I've spent close to 20 years doing web development, and in that time I haven't really thought much about testing. I mean, I've written my share of unit tests and mocks and all that, but I just went with the patterns set by other people on a project, and my tests passed, so I moved on.

Recently, I started work at Pocket as an engineer on our backend team. And one of my first big projects is migrating our admin tools to a dedicated server AND (more my initiative) adopt Symfony and start porting/rewriting our tools to be more unified in both the front- and backend.

Part of that work involved setting up Codecept. I initially tried to leverage what we've done in our main product code, but in the process I did a lot of hacking to include my tests into the bigger set of tests, and furious googling only got me half of what I needed to know.

So I took a breath and started from scratch. This is what I've learned.

Basic Concepts

Before I get into Codecept specifics, I want to talk about some basic testing concepts if it's not familiar to you. (Skip ahead, or read and correct me.)

Automated testing can generally be grouped into the following categories:

Unit Testing: this generally tests specific functions, either through comparing some expected output, or through generating and verifying code execution through test doubles (see below), or a combination of the two. Tests should be isolated and not depend on external dependencies (e.g. no live database or filesystem), hence unit
- Take-away: you want to test that square(x) returns x * x, but you don't want to test if save_to_table('some_table', square(x)) successfully updates the database.
Integration Testing (and Functional Testing): this takes a step back from unit testing. You might still be comparing return results and using test doubles, but you're also using live systems (e.g. a real database or REST endpoint), and the code execution will span a wide range of functions and services (e.g. using a test Symfony framework instance to trigger a request and make sure the expected controller is executed). The goal here is to make sure all those isolated pieces are working nice together.
- Functional testing is a subset of integration testing and is focused more on verifying output of a given system based on the input provided -- you don't need to know what happens along the way, just that you get the results you expected.
Acceptance Testing: the nearly final stage of testing. These build on everything you've done in unit and integration/functional testing and makes sure that the output matches consumer expectation:
- Is a header showing?
- Are the links correct?
- Is the sign-in form working?

Test doubles are objects and functions that get swapped in for real things. Let's say you have a unit test where the function you're testing involves making a REST call, and you want to verify behavior for successes and failures. Instead of making an actual REST call (which should be in the integration test phase), you can pass in a simulated HTTP client that only responds to the behaviors you tell it go (e.g. when get('/url') is called, return this specific response). TestDouble describes specific types of test doubles.

Tests can be organized into suites. You'll have your common unit, functional, and acceptance suites, but you might also have tests that run only on production after a deployment takes place. Suites are a great way to have control over what tests get executed and when.

Installing Codecept

In your PHP project, make sure you're using Composer (LINK HERE), because I haven't setup Codecept any other way. Then do:

composer require "codeception/codeception":"^2.2" --dev

This will make Codecept available for the development environment. Next, you may want to add your project's ./vendor/bin directory to $PATH. This will make codecept available as a script.

Making a Test Skeleton

In your root project directory, type codecept bootstrap. This will generate the following:

codecept.yml
tests/
tests/_data/
tests/_output/
tests/_support/
tests/acceptance/
tests/acceptance.suite.yml
tests/functional/
tests/functional.suite.yml
tests/unit/
tests/unit.suite.yml

Type codecept run to make sure that these empty tests suites successfully load and run.

Note that every suite has a $suite.suite.yml file and $suite/ directory.

Conclusion

That's it! I don't want this intro to be a huge info dump. In Part 2 I'll start getting into specifics.

DEV Community: kaiser shahid

Humane Intro to React (and JSX, and some ES 6)

What is React?

The Checkbox-Textbox Example using jQuery

Conclusion

The Checkbox-Textbox Example in React

ES 6 and JSX Quick Primer

Making Our Component Interactive

State (this.state)

Destructuring (ES 6)

Try it Out

Arrow Functions (ES 6)

Try it Out

Conclusion

Lifting State Up

Nested Components

Properties (this.props)

Using Our New Component

Communicate with Parent Component (indirectly)

Conclusion

Wrapping it Up

How does React do this magic?

Further Readings

Next Up

Codecept For Dummies: Part 2: Concepts

Codecept For Dummies: Part 1: Overview

kaiser shahid ・ Mar 21 '18

Actors (Unit, Functional, Paid Soros Thugs, Whatever)

Helpers

Cepts

Codecept For Dummies: Part 1: Overview

Basic Concepts

Installing Codecept

Making a Test Skeleton

Conclusion

State (`this.state`)

Properties (`this.props`)