🎉 Initial commit
This commit is contained in:
piharpi
@@ -0,0 +1,97 @@
|
||||
---
|
||||
title: React Component with Dot Notation
|
||||
date: 2019-02-19 11:45:47 +07:00
|
||||
tags: [react, javascript, dot-notation]
|
||||
layout: post
|
||||
thumbnail: https://media.giphy.com/media/dIxkmtCuuBQuM9Ux1E/200w_d.gif
|
||||
---
|
||||
|
||||
This is my answer to someone’s question on [StackOverflow](https://stackoverflow.com/questions/49256472/react-how-to-extend-a-component-that-has-child-components-and-keep-them/49258038#answer-49258038). How can we define a React component that is accessible through the dot notation?
|
||||
|
||||
Take a look at the following code. We have the ```Menu``` component and its three children ```Menu.Item:```
|
||||
|
||||
const App = () => (
|
||||
<Menu>
|
||||
<Menu.Item>Home</Menu.Item>
|
||||
<Menu.Item>Blog</Menu.Item>
|
||||
<Menu.Item>About</Menu.Item>
|
||||
</Menu>
|
||||
);
|
||||
|
||||
How can we define a component like ```Menu```? Where it has some kind of “sub-component” that is accessible through a dot notation.
|
||||
|
||||
Well, it’s actually a pretty common pattern. And it’s not really a sub-component, it’s just another component being attached to another one.
|
||||
|
||||
Let’s use the above ```Menu```component for example. We’ll put this component to its own dedicated file: ```menu.js```. First, let’s define these two components separately on this module file:
|
||||
|
||||
// menu.js
|
||||
import React from 'react';
|
||||
|
||||
export const MenuItem = ({ children }) => <li>{children}</li>;
|
||||
|
||||
export default const Menu = ({ children }) => <ul>{children}</ul>;
|
||||
|
||||
It’s just a simple functional component. The ```Menu``` is the parent with ```ul``` tag. And the ```MenuItem``` will act as its children. Now we can use these two components like so:
|
||||
|
||||
import React from 'react';
|
||||
import { render } from 'react-dom';
|
||||
import Menu, { MenuItem } from './menu';
|
||||
|
||||
const App = () => (
|
||||
<Menu>
|
||||
<MenuItem>Home</MenuItem>
|
||||
<MenuItem>Blog</MenuItem>
|
||||
<MenuItem>About</MenuItem>
|
||||
</Menu>
|
||||
);
|
||||
|
||||
render(<App />, document.getElementById('root'));
|
||||
|
||||
Where’s the dot notation? To make our MenuItem component accessible through the dot nation, we can simply attach it to the Menu component as a static property. To do so, we can no longer use the functional component for Menu and switch to the class component instead:
|
||||
|
||||
// menu.js
|
||||
import React, { Component } from 'react';
|
||||
|
||||
export default const MenuItem = ({ children }) => <li>{children}</li>;
|
||||
|
||||
export default class Menu extends Component {
|
||||
static Item = MenuItem;
|
||||
|
||||
render() {
|
||||
return (
|
||||
<ul>{this.props.children}</ul>
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
Now we can use the dot notation to declare the ```MenuItem``` component:
|
||||
|
||||
import React from 'react';
|
||||
import { render } from 'react-dom';
|
||||
import Menu from './menu';
|
||||
|
||||
const App = () => (
|
||||
<Menu>
|
||||
<Menu.Item>Home</Menu.Item>
|
||||
<Menu.Item>Blog</Menu.Item>
|
||||
<Menu.Item>About</Menu.Item>
|
||||
</Menu>
|
||||
);
|
||||
|
||||
render(<App />, document.getElementById('root'));
|
||||
|
||||
You can also put the ```MenuItem``` component definition directly within the ```Menu``` class. But this way you can no longer import ```MenuItem``` individually.
|
||||
|
||||
import React, { Component } from 'react';
|
||||
|
||||
export default class Menu extends Component {
|
||||
static Item = ({ children }) => <li>{children}</li>;
|
||||
|
||||
render() {
|
||||
return (
|
||||
<ul>{this.props.children}</ul>
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
**For demo purpose**, Originally published at <https://bagja.net>.
|
||||
69
_posts/_tips/2019-01-26-buccaner-bucko-jury-mast-rum.md
Normal file
69
_posts/_tips/2019-01-26-buccaner-bucko-jury-mast-rum.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: How to name Sass color variables
|
||||
date: 2018-11-18 11:45:47 +07:00
|
||||
tags: [css, sass, naming-variables]
|
||||
layout: post
|
||||
comment: true
|
||||
thumbnail: https://source.unsplash.com/FWCUZqXCrUs/800x480
|
||||
---
|
||||
|
||||
When it comes to naming Sass variables, I suck. I think I've found the perfect solution, get half way through a project, and realise what a terrible mistake I'd made.
|
||||
|
||||
Variables in any language are often overlooked. They're treated as these things that 'ultimately only developers will see, so who cares'. But having a proper naming convention can really help save time, keep your code DRY, and more importantly make your codebase easier to understand for other developers.
|
||||
|
||||
## The bad
|
||||
|
||||
So let's start with the bad. Going back a few months, this is pretty much what the variables file in all of my old projects looked like:
|
||||
|
||||
$red: #e03c31;
|
||||
$darker-red: #c1271d;
|
||||
$blue: #00f;
|
||||
$text-color: #1a1a1a;
|
||||
|
||||
What's the problem here?
|
||||
- The variable names provide no clues as to where they sit in the hierarchy, or their relationship with one another.
|
||||
- What's the primary color? Red? Blue?
|
||||
- What happens if our color scheme changes? We suddenly have to change every instance of ```$red```, with our new color. These defeats the point of having variables in the first place.
|
||||
- _'Darker Red'_ ? How much darker is darker?
|
||||
|
||||
|
||||
## Better
|
||||
|
||||
$primary-color: #e03c31;
|
||||
$secondary-color: #7fff00;
|
||||
$text-color: #1a1a1a;
|
||||
|
||||
Now we've provided some context, we can better see the relationship between our colors. We have a ```$primary-color``` and ```$secondary-color```, which would be our brand colors, and then provide some other utility variables such as ```$text-color```.
|
||||
|
||||
|
||||
## Even Better
|
||||
|
||||
// Internal variables
|
||||
$x-palette-red: #e03c31;
|
||||
$x-palette-green: #7fff00;
|
||||
|
||||
// Global variables
|
||||
$palette-primary: $x-color-red;
|
||||
$palette-secondary: $x-color-green;
|
||||
|
||||
$palette-paragraph: #1a1a1a;
|
||||
|
||||
This is a method that I've recently started using in all of my new projects.
|
||||
|
||||
First we define our colors at a very high level using internal variables. I like to prefix my internal variables with ```x```. Internal variables have one function, and that's to be assigned to other variables. This allows us to keep our global variables free of any bias, but also informs us and others working on the codebase what the actual palette color is. Because let's face it, hex codes are for machines.
|
||||
|
||||
We've also switched around the naming of the actual color variables, to follow a 'property -> level' convention. This is particulary useful when these are surrounded by other variables for typography, grids, etc., as we can instantly scan our variables file by property.
|
||||
|
||||
$palette-primary: $x-color-red;
|
||||
$palette-secondary: $x-color-blue;
|
||||
$palette-tertiary: $x-color-green;
|
||||
|
||||
$font-family-primary: 'Helvetica Neue', sans-serif;
|
||||
$font-family-secondary: 'Georgia', serif;
|
||||
|
||||
$line-height-base: 18px;
|
||||
$line-height-paragraph: 16px;
|
||||
|
||||
Likewise, we use the word 'palette' to distinguish our variables from the 'color' css property which is exclusively for text color.
|
||||
|
||||
**For demo purpose**, Originally published at <https://fahmiirsyd.com>.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: How to Clear Nunjucks Cache
|
||||
date: 2019-02-19 11:45:47 +07:00
|
||||
modified: 2019-02-20 11:45:47 +07:00
|
||||
tags: [nonjuck, cache, pug, flores, static-site]
|
||||
layout: post
|
||||
---
|
||||
I’m building a static site generator (again) named [Flores](). Initially, I use [Pug]() for the templating engine. But then I discovered [Nunjucks](). It has a lot more features and the syntax is quite similar to [Twig]() which I’m familiar with. I also did a quick test and the render time is quite similar when the cache option is activated.
|
||||
|
||||
However, I had an issue when Flores is on the “watch” mode (think of Webpack watch mode). When the user edits the template file, the changes won’t be reflected on the generated HTML files. This thing happened because of Nunjucks cached the compiled template. The thing is there’s no mention in Nunjucks documentation on how to manually clear the cache.
|
||||
|
||||
I dug into the [Nunjucks source code](https://github.com/mozilla/nunjucks) and found out that each Nunjucks loader (the object that responsible for loading the template) uses cache property to store the compiled template. You can check it on [```initCache```](https://github.com/mozilla/nunjucks/blob/v3.1.7/nunjucks/src/environment.js#L98-L108) method on ```Environment``` class.
|
||||
|
||||
// src/environment.js
|
||||
initCache() {
|
||||
// Caching and cache busting
|
||||
this.loaders.forEach((loader) => {
|
||||
loader.cache = {};
|
||||
if (typeof loader.on === 'function') {
|
||||
loader.on('update', (template) => {
|
||||
loader.cache[template] = null;
|
||||
});
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
So in order to clear all the caches, all I have to do is simply set this ```cache``` property to an empty object again.
|
||||
|
||||
const nunjucks = require("nunjucks");
|
||||
|
||||
const env = nunjucks.configure("./path/to/templates");
|
||||
|
||||
for (let i = 0; i < env.loaders.length; i += 1) {
|
||||
env.loaders[i].cache = {};
|
||||
}
|
||||
|
||||
**For demo purpose**, Originally published at <https://bagja.net>.
|
||||
Reference in New Issue
Block a user