Developing with Scandi
Tutorials
#5 Patterns of ScandiPWA
Learning the way (tutorial 4)
In this tutorial we will talk about the main component files in ScandiPWA:
After watching this tutorial you should be able to discuss the following:
- Using VSCode extension for component bootstrap
- Top-level contents must be exported in .config file
- Map property principle
- Escaping for loops and lets
To follow along with this tutorial, you should start with the environment set-up. For this demonstration we’ll be using VSCode.
Run
yarn start to start the development server and add an index.js file to the src folder:1
📂<your-app-name>
2
┣ 📂i18n
3
┣ 📂magento
4
┣ 📂node_modules
5
┣ 📂public
6
┣ 📂src
7
┃ ┗ 📜index.js # new file
8
┣ 📜composer.json
9
┣ 📜package.json
10
┗ 📜yarn.lock
Copied!
The
index.js file should look like this:1
import ReactDOM from 'react-dom';
2
3
ReactDOM.render(
4
<UrlResolver />,
5
document.getElementById('root')
6
);
Copied!
You’ll see an error saying ‘UrlResolver’ is not defined. If you’ve followed along with the environment set-up, you’ll already have ScandiPWA Development Toolkit installed, which will be necessary for the rest of this tutorial.
To resolve the ‘not defined’ issue, press
ctrl + shift + P to access the VSCode command pallette and type in ‘>Create new component’ and press enter.You should then be prompted to type in your new component’s name, in this case it’s
UrlResolver, select the Contains business logic feature and press enter.The ScandiPWA Development Toolkit will generate a ScandiPWA
UrlResolver component folder which will contain template files:1
📂<your-app-name>
2
┣ 📂i18n
3
┣ 📂magento
4
┣ 📂node_modules
5
┣ 📂public
6
┣ 📂src
7
┃ ┣ 📂component/UrlResolver
8
┃ ┃ ┣ 📜index.js
9
┃ ┃ ┣ 📜UrlResolver.component.js
10
┃ ┃ ┣ 📜UrlResolver.container.js
11
┃ ┃ ┗ 📜UrlResolver.style.scss
12
┃ ┗ 📜index.js
13
┣ 📜composer.json
14
┣ 📜package.json
15
┗ 📜yarn.lock
Copied!
If you have any issues with the imports, ScandiPWA Development Toolkit allows you to click on your issue and ‘Fix all auto-fixable problems’.
So, now we can go back to
src/index.js and import the UrlResolver:1
import ReactDOM from 'react-dom';
2
3
import UrlResolver from 'Component/UrlResolver';
4
5
ReactDOM.render(
6
<UrlResolver />,
7
document.getElementById('root')
8
);
Copied!
Notice that we don’t have to use the relative path, instead we can use an alias for the absolute path of the
Component folder.You can check out what path aliases are available by going to
node_modules/@scandipwa/scandipwa/src. The folders here represent the available aliases and these are as follows: component, query, route, store, style, type and util. The alias for referencing these folders is simply the folder name - capitalized..component
Using the previously created
component/UrlResolver folder, let’s edit the UrlResolver.component.js file:1
// some stuff
2
3
render() {
4
return (
5
<div block="UrlResolver">
6
Hello!
7
</div>
8
);
9
}
Copied!
If you go to Chrome
localhost:3000, you’ll see the ‘Hello!’ being output there.NOTE
The main tasks of
UrlResolver.component.js are:- Determining the page type
- Rendering the proper page
So, we’ll need to take a URL using the location API and we’ll need to detect to which entity type the URL refers to, e.g. a page, a category or a product.
First, let’s look at page rendering. Let’s assume that there are multiple page types. How can we render them?
Since the
component.js files are made for pure rendering, we’ll assume that the page type will be coming from props and we’ll not determine page type in the component.The URL determination will be done in the
container.js and we’ll tackle that a bit later.Let’s assume that the
container ships us a type as a prop:1
import PropTypes from 'prop-types';
2
import { PureComponent } from 'react';
3
4
import './UrlResolver.style';
5
6
class UrlResolver extends PureComponent {
7
static propTypes = {
8
// a propType of type string is required
9
type: PropTypes.string.isRequired
10
};
11
12
render() {
13
const { type } = this.props;
14
15
if (type === 'product') {
16
return 'product';
17
}
18
19
if (type === 'category') {
20
return 'category';
21
}
22
return 'cms_page';
23
}
24
}
Copied!
Let’s add individual render methods for each product type:
1
import PropTypes from 'prop-types';
2
import { PureComponent } from 'react';
3
4
import './UrlResolver.style';
5
6
class UrlResolver extends PureComponent {
7
static propTypes = {
8
// a propType of type string is required
9
type: PropTypes.string.isRequired
10
};
11
12
renderProduct() {
13
return 'product';
14
}
15
16
renderCategory() {
17
return 'category';
18
}
19
20
renderCmsPage() {
21
return 'cms_page';
22
}
23
24
render404() {
25
return '404';
26
}
27
28
render() {
29
const { type } = this.props;
30
31
if (type === PRODUCT_TYPE) {
32
return this.renderProduct();
33
}
34
35
if (type === CATEGORY_TYPE) {
36
return this.renderCategory();
37
}
38
return this.renderCmsPage();
39
}
40
// some stuff
41
}
Copied!
.config
Add the product page types as constants in
UrlResolver.config.js:1
export const PRODUCT_TYPE = 'product';
2
export const CATEGORY_TYPE = 'category';
3
export const CMS_PAGE_TYPE = 'cms_page';
Copied!
We shouldn’t add the constants to the
component.js file due to the fact that in order for webpack to be able to create smaller sized bundles, we need to add the constants that might be reused by different modules to the config.js file - outside of large modules.webpack can’t split modules apart, so, if only a constant is needed, the bundle size would be minimized significally by using a constant-only file. In this case, creating a new file means creating a new module.The issue with our
UrlResolver.component.js file now is that the code repeats itself. An option is to write switch statements instead of if statements:1
// some stuff
2
3
render(){
4
const { type } = this.props;
5
6
switch (type) {
7
case PRODUCT_TYPE:
8
return this.renderProduct();
9
case CATEGORY_TYPE:
10
return this.renderCategory();
11
case CMS_PAGE_TYPE:
12
return this.renderCmsPage();
13
default:
14
return this.render404();
15
}
16
}
Copied!
Notice that ScandiPWA has a specific writing convention in place for
switch statements - the cases should be on the same indentation level as the switch itself.Since we haven’t imported the constants from the
config file, we can use auto-fixer to ‘Fix this simple import-sort/sort problem’ and it’ll add the following to our imports:1
import PropTypes from 'prop-types';
2
import { PureComponent } from 'react';
3
4
import {
5
CATEGORY_TYPE,
6
CMS_PAGE_TYPE,
7
PRODUCT_TYPE
8
} from './UrlResolver.config';
9
10
import './UrlResolver.style';
Copied!
If we check-in with the browser,
localhost:3000 will display ‘404’ as the type of page hasn’t yet been passed, it’s undefined.Map approach for component types
The
switch approach for component types is still not the most efficient way to go about rendering since we can’t quickly extend the method. The solution to this is to create a rendering map:1
class UrlResolver extends PureComponent {
2
static propTypes = {
3
type: PropTypes.string.isRequired
4
};
5
6
renderMap = {
7
[CATEGORY_TYPE]: this.renderCategory.bind(this),
8
[PRODUCT_TYPE]: this.renderProduct.bind(this),
9
[CMS_PAGE_TYPE]: this.renderCmsPage.bind(this),
10
};
11
12
// other stuff
Copied!
As you might know
this can cause context loss, so we need to bind the type to the render method.After creating the render map, we need to replace our
switch statement:1
// some stuff
2
3
render(){
4
const { type } = this.props;
5
6
const renderFunction = this.renderMap[type];
7
8
if (renderFunction) {
9
return renderFunction();
10
}
11
12
return this.render404();
13
14
}
Copied!
We can further optimize this by using the logical operator OR (||)
1
// some stuff
2
3
render(){
4
const { type } = this.props;
5
6
const renderFunction = this.renderMap[type] || this.render404.bind(this);
7
return renderFunction();
8
}
Copied!
In both cases our render will return ‘404’ in the case if no type was found.
So, the finalized
component file will look like this:1
import PropTypes from 'prop-types';
2
import { PureComponent } from 'react';
3
4
import {
5
CATEGORY_TYPE,
6
CMS_PAGE_TYPE,
7
PRODUCT_TYPE
8
} from './UrlResolver.config';
9
10
import './UrlResolver.style';
11
12
class UrlResolver extends PureComponent {
13
static propTypes = {
14
type: PropTypes.string.isRequired
15
};
16
17
renderMap = {
18
[CATEGORY_TYPE]: this.renderCategory.bind(this),
19
[PRODUCT_TYPE]: this.renderProduct.bind(this),
20
[CMS_PAGE_TYPE]: this.renderCmsPage.bind(this),
21
// add a new [KEY] to object to extend
22
// type constants are in config file
23
};
24
25
renderProduct() {
26
return 'product';
27
}
28
29
renderCategory() {
30
return 'category';
31
}
32
33
renderCmsPage() {
34
return 'cms_page';
35
}
36
37
render404() {
38
return '404';
39
}
40
41
render(){
42
const { type } = this.props;
43
44
const renderFunction = this.renderMap[type] || this.render404.bind(this);
45
return renderFunction();
46
}
47
}
48
49
export default UrlResolver;
Copied!
.container
The
container has all of the business logic inside of it. So, in order to determine the URL, we should go to the URL container. We can try to guess the URL type based on the URL, but we can also request the URL from the Magento URL resolver aka UrlRewrite\resolve.For now, let’s just guess which type we’re referring to based on the location. So, to actually do it we should first understand the concept of a
container.Container structure: containerProps, containerFunctions
A
container file has two functions always defined:1
containerFunctions = {
2
// getData: this.getData.bind(this)
3
};
4
5
containerProps = () => {
6
// isDisabled: this._getIsDisabled()
7
};
Copied!
containerFunctions is an object containing the mapping of a key that will be later passed to your component as a prop and the function that’ll be used to implement the prop.The
getData key will be passed as a prop to the component, where it’ll call it and then it’ll return some data. So, the logic itself will be located in the container and the component will simply call it.We won’t be using the
containerFunctions in this tutorial, so we can remove all references to it from the container file.Next are the
containerProps which are meant for props mapping. For example, if you have a property to define, like isDisabled or a type, you provide a function that will get this property for you.Again, the property itself is used in the
component for rendering, but the value retrieved from the container.In order to determine the page type let’s do the following in the
container.js file.1
// add () to get a valid object returned, instead of a function
2
containerProps = () => ({
3
type: this._getTypeFromURL()
4
});
5
6
_getTypeFromURL() {
7
return PRODUCT_TYPE;
8
}
9
10
// some stuff
Copied!
In order to use
PRODUCT_TYPE we also need to import it in the UrlResolver.container.js file:1
import { PureComponent } from 'react';
2
3
import UrlResolver from './UrlResolver.component';
4
import { PRODUCT_TYPE } from './UrlResolver.config';
Copied!
If we compile and go to
localhost:3000 in our browser, we should see ‘product’ now.Now, we need to implement mapping itself. Let’s assume that the page we’re visiting contains the type and the URL. This means that we need to implement mapping again. This time instead of mapping to a function, let’s use regex, since it’s one of the faster ways to find strings.
1
// some stuff
2
3
typeMap = {
4
[CATEGORY_TYPE]: /category/,
5
[PRODUCT_TYPE]: /product/,
6
[CMS_PAGE_TYPE]: /page/,
7
};
8
9
containerProps = () => ({
10
type: this._getTypeFromURL()
11
});
12
13
_getTypeFromURL() {
14
// eslint-disable-next-line fp/no-let
15
for (let i = 0; i < Object.entries.(this.typeMap).length; i++){
16
const [type, regex] = Object.entries(this.typeMap)[i];
17
18
// checking if the provided path name matches
19
if (regex.test(window.location.pathname)) {
20
return type;
21
}
22
}
23
return ''; // will be handled as 404 by component
24
}
Copied!
Disable any ESlint warnings and don’t forget to:
1
import {
2
CATEGORY_TYPE,
3
CMS_PAGE_TYPE,
4
PRODUCT_TYPE
5
} from './UrlResolver.config';
Copied!
So in
localhost:3000 we’ll see ‘404’, but if we go to localhost:3000/product in our browser, we’ll see ‘product’.A way of optimizing the for loop would be by defining the array beforehand:
1
_getTypeFromURL() {
2
const array = Object.entries.(this.typeMap);
3
4
// eslint-disable-next-line fp/no-let
5
for (let i = 0; i < array.length; i++){
6
const [type, regex] = array[i];
7
8
// checking if the provided path name matches
9
if (regex.test(window.location.pathname)) {
10
return type;
11
}
12
}
13
return ''; // will be handled as 404 by component
14
}
Copied!
Instead of the type map, we should make a type list that’ll work as an array. This will work much better for us, as it’ll be possible to loop through it right away:
1
typeList = [
2
{
3
type: CATEGORY_TYPE,
4
regex: /category/
5
},
6
{
7
type: CMS_PAGE_TYPE,
8
regex: /page/
9
},
10
{
11
type: PRODUCT_TYPE,
12
regex: /product/
13
},
14
]
15
16
containerProps = () => ({
17
type: this._getTypeFromURL()
18
});
19
20
_getTypeFromURL() {
21
// eslint-disable-next-line fp/no-let
22
for (let i = 0; i < this.typeList.length; i++){
23
const { type, regex } = this.typeList[i];
24
25
// checking if the provided path name matches
26
if (regex.test(window.location.pathname)) {
27
return type;
28
}
29
}
30
return ''; // will be handled as 404 by component
31
}
Copied!
Another way of optimizing would be by using array functions:
1
_getTypeFromURL() {
2
const { type } = this.typeList.find(
3
({ type, regex }) => regex.test(window.location.pathname)
4
);
5
return type;
6
}
Copied!
An issue with using
find is that it can return null. In this case, we’ll get a TypeError: Cannot destructure property ‘type’ because it’s undefined.A solution would be to return an empty array in case nothing is found. If an empty array is destructured the type is ‘undefined’, this then can be handled by the
component:1
_getTypeFromURL() {
2
const { type } = this.typeList.find(
3
({ type, regex }) => regex.test(window.location.pathname)
4
) || {};
5
6
return type; // will be handled as 404 if undefined by component
7
}
Copied!
We can see that by using
typeList the rest of our logic shrunk down as well. This is why we need to understand which data structure is needed before attempting to implement anything.For example, arrays come in handy when you need to find something, but for rendering, maps are a better solution.
.style
Let’s go back to the
UrlResolver.component.js file and implement renderType as a separate function. This is needed because the render itself should return the style wrapper:1
// some stuff
2
3
render404() {
4
return '404';
5
}
6
7
renderType() {
8
const { type = '404' } = this.props;
9
const renderFunction = this.renderMap[type] || this.render404.bin(this);
10
return (
11
<article
12
block="UrlResolver"
13
elem="Type"
14
mods={ { type } }
15
>
16
{ renderFunction();}
17
</article>
18
);
19
}
20
21
render(){
22
return (
23
<main block="UrlResolver">
24
{ this.renderType() }
25
</main>
26
);
27
}
28
}
29
30
export default UrlResolver;
Copied!
Wrapping the
renderFunction in article ensures that we’ll be able to refer to it using a BEM abstraction later on.Go to
UrlResolver.style.scss to apply some styles. If you want to take an in-depth look at ScandiPWA styling conventions, go here.1
:root {
2
--url-resolver-color: orange;
3
}
4
5
.UrlResolver {
6
font-size: 20px;
7
8
&-Type {
9
color: var(--url-resolver-color);
10
11
// type specific colors
12
&_type {
13
&_404 {
14
color: red;
15
}
16
}
17
}
18
}
Copied!
The issue with
&_404 { color: red; } is that we’re redefining a property, instead, we should redefine the CSS custom variable:1
:root {
2
--url-resolver-color: orange;
3
}
4
5
.UrlResolver {
6
font-size: 20px;
7
8
&-Type {
9
color: var(--url-resolver-color);
10
11
// type specific colors
12
&_type {
13
&_404 {
14
--url-resolver-color: red;
15
}
16
}
17
}
18
}
Copied!
What if we move the variable declaration a level up?
1
:root {
2
--url-resolver-color: orange;
3
}
4
5
.UrlResolver {
6
font-size: 20px;
7
color: var(--url-resolver-color);
8
9
&-Type {
10
&_type {
11
&_404 {
12
--url-resolver-color: red;
13
}
14
}
15
}
16
}
Copied!
Now, the logic will stop working and ‘404’ will be orange. As mentioned in the previous tutorial the CSS custom variables are resolved from the top of the file.
The first element it’ll look at is the and there the variable will be defined in
:root{}. Going further down to, and further on we can see no declarations of this variable.It’ll not care if the variable declaration appears inside the element, it only cares if the declaration happens above the element.
This is why color property declarations should appear on the same level or deeper than the variable re-declaration.
The only thing left to do is to get rid of the hardcoded red:
1
:root {
2
--url-resolver-color: orange;
3
--url-resolver-404-color: red;
4
}
5
6
.UrlResolver {
7
font-size: 20px;
8
color: var(--url-resolver-color);
9
10
&-Type {
11
&_type {
12
&_404 {
13
--url-resolver-color: var(--url-resolver-404-color);
14
}
15
}
16
}
17
}
Copied!
Last modified 10mo ago