DEV Community: Nozomu Ikuta

Vue RFCs: Changs on Global APIs and related things

Nozomu Ikuta — Sun, 26 Jan 2020 14:53:58 +0000

Introduction

I summarized what changes will come in Vue 3, especially about global API related things.

Self-contained apps
Tree-shaking support
APIs that are no longer supported

Self-contained apps

Problem

With Vue 2, all Vue applications in a page are affected by some global APIs at the same time. This is because their behavior derives from only one root constructor, Vue().

// In Page A...

Vue.config.ignoredElements = [/* ... */]
Vue.use(/* ... */)
Vue.mixin(/* ... */)
Vue.component(/* ... */)
Vue.directive(/* ... */)

// will affect all the apps

const appA = new Vue({ ... })
const appB = new Vue({ ... })
const appC = new Vue({ ... })

Solution

As of Vue 3, Vue applications come to be created via createApp() function, and the apps are self-contained and have no influence on each other.

// Vue.use() is no longer available

const appA = createApp({ ... })
const appB = createApp({ ... })
const appC = createApp({ ... })

// Each app has "global" API to change its own behavior only
appA.use(plugin)
appA.config.ignoredElements = [/* ... */]
appA.use(/* ... */)
appA.mixin(/* ... */)
appA.component(/* ... */)
appA.directive(/* ... */)

// And `new Vue().$mount()` is replaced by app's `mount()` method.
app.mount(App, '#app')

If you want to know more detail, see RFC0009.

Tree-shaking support

Problem

While some global APIs change Vue's behavior as above, other don't do that but just provide utilities.

In Vue 2, all global APIs are registered on Vue() constructor function so that they are always included in the bundle files, which results in larger size of bundle files.

Solution

In Vue 3, global APIs which don't change Vue's (or each app's) behavior are no longer registered on Vue() constructor function. In other words, they are no longer automatically included in the bundle files. Instead, we can import them only when we need.

Vue.nextTick()
Vue.observable()
Vue.version
Vue.compile()
Vue.set()
Vue.delete()

import { nextTick } from 'vue'

nextTick().then(() => console.log('hello!'))

If you want to know more detail, see RFC0004.

APIs that are no longer supported

In this section, I will refer to APIs which are no longer supported.

Firstly, Vue.config.productionTip is no longer provided because in most cases there is alternative way to achieve the goal that this API is for. See this part of RFC0009 for more detail.

Secondly, Vue.config.ignoredElements is replaced by config.isCustomElement() function of each application. See this part of RFC0009 from more detail.

Thirdly, Vue.config.keyCodes is no longer available. In Vue 3, KeyboardEvent.key is used as v-on modifier. Actually, KeyboardEvent.keyCode is deprecated and replaced by KeyboardEvent.key. That is, this API is simply redundant. See RFC0014 from more detail.

Summary

In this post, it is explained that Vue 3's Global API changes. I will try to summarized other active RFCs as well.

Change on study plan (2)

Nozomu Ikuta — Thu, 16 Jan 2020 12:27:55 +0000

Since first day of the year, I have been writing posts everyday.

But, I found that every single day is not enough long to write posts that are informative to others.

As far as I see articles posted on DEV Community, well-summarized and relatively longer post seems to “get popular”. Popularity and usefulness are not necessarily cause and effect, but I think they are correlated.

I will try to make posts every Monday for the time being.

What I learned so far by writing 14 posts everyday

Nozomu Ikuta — Wed, 15 Jan 2020 14:59:05 +0000

What I learned so far by writing 14 posts everyday

Pros

To collect topics about which I write a post everyday, I became more eager to keep studying (someone says that now method became more important than its purpose. But, What I can get as a result is the most important 😄)
To submit a post everyday, I came to be more careful with time management
I'm feeling I became A little bit more familiar with English language

Cons

So hard! (just because I work everyday, too!)
Each post is likely to be shorter and less informative
...It's 11:46 p.m. now...hurry up...

What I should do for better performance

Acquire fluency in English so that I can write faster
Learn how to summarize and visualized what I learn everyday
Learn how to write posts informative to others

As for third task, the reason is that I'm "taking a room" in this community site. Even if they are so open-minded, here is not my personal space. In addition, I want to give back something to others as anonymous people on the web did for me when I was a newbie.)

Study Log: Reading Vue's RFCs (3)

Nozomu Ikuta — Tue, 14 Jan 2020 11:12:56 +0000

I've read all the Vue's active RFCs and related documents.

I categorized them into some groups according to the topics and am going to share it at internal study meeting in my company.

Besides the meeting, I, by myself, will study RFCs in more depth so that I can summarized them in the way the article can be more informative to Dev community.

I decided to continue to keep posting, and also tweet my posts with hash tag.

I believing in openness of this community, but I do appreciate if you tell me the more valuable way I can contribute to the community.

Study Log: Reading Vue's RFCs (2)

Nozomu Ikuta — Mon, 13 Jan 2020 14:53:30 +0000

Continued from the last post, I've reading active RFCs of Vue.js.

Now, I'm reading the last one, composition API, which I skipped at first because it is long.

I would like to visualize what I learned about RFCs. That's because the reason I write posts every day is not only keep my motivation to learn things but improving skills of writing about them in English. I hope trying new ways would be helpful for that purpose.

By the way, I'm feeling that most of posts I've wrote so far are not informative to other people in this community. They are just "memo" about my study. Should it be Twitter that I write down daily thoughts?
I'm not sure to what extent the contents can be written freely.

In addition, I'm tweeting every time I write a post with #DevCommunity hash tag. Should it be only when I think the post is informative to others in the community that I add this tag?

I decided to not attach 2020 tag to posts of my devjournal since it's included in the title of the series. This change is applied to the past posts as well.

Study Log: Reading Vue's RFCs

Nozomu Ikuta — Sun, 12 Jan 2020 14:41:51 +0000

In the last post of "My Dev Journal of 2020" series, I decided to research and summarize RFCs of Vue.js.

I've read 9 of 18 active RFCs and am reading 10th, which is about new design of v-model API.

I would be able to finish reading all RFCs in tomorrow.

Change on study plan

Nozomu Ikuta — Sat, 11 Jan 2020 14:59:16 +0000

I've been writing a series since few days ago.

But, through next week, I have to research new features of the next version of Vue.js, which are not yet well-documented.

I will share them with DEV community when it's done.

This post has been written just for devjournal of my own.

How can I read source code and summarize them more efficiently?

Nozomu Ikuta — Fri, 10 Jan 2020 07:33:02 +0000

How can I read OSS source code and summarize them more efficiently?

I've been writing a series whose name is "How lit-html works" since days ago, which is one of my goals for 2020.

Writing posts everyday was harder than I expected. But it is also exciting and making me motivated.

Now I'm thinking that the way I'm doing is not efficient. That is, reading parts of source code everyday and write a post about them. In this way, I can't understand a part accurately at that time I read the part, because I don't know whole picture in advance.

I would like to hear your ideas or way to read source code, especially OSS.

Exploring How lit-html Works: render Function

Nozomu Ikuta — Thu, 09 Jan 2020 09:37:47 +0000

In this series, How lit-html works, I will explore (not explain) internal implementation of lit-html.

In the last 4 posts, we saw what TemplateResult and SVGTemplateResult looks like.

From now on, I will explore the render function.

`render` function

render function is defined beside a variable whose name is parts.

export const parts = new WeakMap<Node, NodePart>();

export const render =
    (result: unknown,
     container: Element|DocumentFragment,
     options?: Partial<RenderOptions>) => {
      let part = parts.get(container);
      if (part === undefined) {
        removeNodes(container, container.firstChild);
        parts.set(
            container,
            part = new NodePart(
                {
                  templateFactory,
                  ...options,
                },
                undefined));
        part.appendInto(container);
      }
      part.setValue(result);
      part.commit();
    };

This function receives two arguments. First one is an instance of TemplateResult or SVGTemplateResult. Second is the container, which is a DOM parent inside which the content is rendered.

Searching Cache

Firstly, render function checks if an instance of NodePart class is stored in parts with the container as a key.

Create a New `NodePart`

If a cached NodePart instance is not found, then all the direct children of the container are removed by removeNodes function.

export const removeNodes =
    (container: Node, start: Node|null, end: Node|null = null): void => {
      while (start !== end) {
        const n = start!.nextSibling;
        container.removeChild(start!);
        start = n;
      }
    };

The algorithm is quite similar to reparentNodes function that I saw in the last post. Only difference is how the functions manipulate DOM tree.

After cleaning up the container, a new NodePart instance is registered into the parts and is associated with with the container.

Rendering

Finally, render function lets the NodePart instance call three methods of it, but I will explore this part in later posts. Instead, I will recap what WeakMap is, because it's worth using in other development as well.

WeakMap

MDN says that the WeakMap object is a collection of key/value pairs and the keys must be objects.

The word "weak" here means that the reference from weak map to the key object doesn't prevent the object from being garbage collected.

Thus, it is really convenient to store data in a WeakMap as a cache. We don't have to check, every time we do something or periodically the data of the object, whether the data is no longer used.

Just for information, there are also Map, Set, WeakSet, each of which has suitable situation.

Summary

So far, I learned the following points:

render function caches NodePart.
render function creates a new NodePart if no corresponding cache is found.
render function delegates actual rendering process to the NodePart instance.

From the next post, I will dive into the NodePart class.

Exploring How lit-html Works: TemplateResult and SVGTemplateResult constructors (4)

Nozomu Ikuta — Wed, 08 Jan 2020 10:23:04 +0000

In this series, How lit-html works, I will explore (not explain) internal implementation of lit-html.

In the previous post, we saw how getHTML() method of TemplateResult class handles attribute expressions and it cannot always parse comment-like string as expected.

In this post, I will explore the reparentNodes function, which is also one that I skipped in the past post.

Recap of `getTemplateElement()` method of `SVGTemplateResult` class

getTemplateElement(): HTMLTemplateElement {
  const template = super.getTemplateElement();
  const content = template.content;
  const svgElement = content.firstChild!;
  content.removeChild(svgElement);
  reparentNodes(content, svgElement.firstChild);
  return template;
}

getTemplateElement() method removes the redundant svg element from the content of HTML template element, which is originally added by getHTML() method.

If I passed this string to svg tag function, the string returned by getHTML() method is like that below.

const templateResult = svg`
  <svg id="my-svg">
    <circle cx="100" cy="100" r="100"/>
  </svg>
  <svg id="my-another-svg">
    <circle cx="100" cy="100" r="100"/>
  </svg>
`

console.log(templateResult.getHTML())
// => 
// <svg>
//  <svg id="my-svg">
//    <circle cx="100" cy="100" r="100"/>
//  </svg>
//  <svg id="my-another-svg">
//    <circle cx="100" cy="100" r="100"/>
//  </svg>
// </svg>

Then, the root svg element added by getHTML() method is removed from the content of the HTML template element.

const svgElement = content.firstChild;
content.removeChild(svgElement);

console.log(template)
// => shown like below and #document-fragment is empty...
// <template>
//   #document-fragment
// </template>

After this process is the place where reparentNodes function comes into play.

`reparentNodes` function

reparentNodes is called with the content as container and first child of the extra svg element, in other words, svg element whose id is my-svg.

export const reparentNodes =
    (container: Node,
     start: Node|null,
     end: Node|null = null,
     before: Node|null = null): void => {
      while (start !== end) {
        const n = start!.nextSibling;
        container.insertBefore(start!, before);
        start = n;
      }
    };

In first while loop, since start (svg element whose id is my-svg) is not the same as end (null), the element is inserted to the container as the last child.

In second while loop, since start (svg element whose id is my-another-svg) is also not the same as end (null), the element is inserted to the container as the last child.

In third while loop, since start (nextSibling of the svg element whose id is my-another-svg) is the same as end (null), the loop breaks.

The reasons all the elements are inserted as the last child is that, as written in MDN, Node.insertBefore(newNode, referenceNode) method inserts newNode as the last child to the Node, if referenceNode node is null.

So, it is guaranteed that the order of elements of which the original string is consist of doesn't change.

Finally, the HTML template element is again consisted of the original elements without the redundant svg element.

console.log(template)
// => shown like below...
// <template>
//   #document-fragment
//    <svg id="my-svg">
//      <circle cx="100" cy="100" r="100"/>
//    </svg>
//    <svg id="my-another-svg">
//      <circle cx="100" cy="100" r="100"/>
//    </svg>
// </template>

reparentNodes function is used in other places in lit-html so I will encounter it again later.

In addition, lit-html is exporting reparentNodes function so that you can use this function as utility if you want (e.g. extending lit-html).

Summary

So far, I learned the following points:

(Again) getHTML() method of SVGTemplateResult class adds a extra svg element to the original template so that it can be parsed in the correct namespace.
getTemplateElement() method returns template element, with only the extra svg element removed.
Part of this unwrapping operation is done by reparentNodes function, which is exported, and is available to developers.

Now, I've explored all the methods of TemplateResult and SVGTemplateResult class.

From the next post, I will dive into the render function, which is another essential part of lit-html, to know how the library renders the content of HTML template element to the real DOM tree.

Exploring How lit-html Works: TemplateResult and SVGTemplateResult constructors (3)

Nozomu Ikuta — Tue, 07 Jan 2020 13:53:15 +0000

In this series, How lit-html works, I will explore (not explain) internal implementation of lit-html.

In the previous post, we saw how how lit-html uses Trusted Types API to convert template strings to trusted HTML string.

In this post, I will dive into getHTML() method of TemplateResult more deeply.

Handling Comment-Like Expressions in the Template Literals

In the past post, I said that if-statements and related lines in getHTML() method of TemplateResult class are to handle comment-like strings.

Let's look into this point.

getHTML(): string {
  const l = this.strings.length - 1;
  let html = '';
  let isCommentBinding = false;

  for (let i = 0; i < l; i++) {
    const s = this.strings[i];

    const commentOpen = s.lastIndexOf('<!--');
    isCommentBinding = (commentOpen > -1 || isCommentBinding) &&
        s.indexOf('-->', commentOpen + 1) === -1;

    const attributeMatch = lastAttributeNameRegex.exec(s);
    if (attributeMatch === null) {
      html += s + (isCommentBinding ? commentMarker : nodeMarker);
    } else {
      html += s.substr(0, attributeMatch.index) + attributeMatch[1] +
          attributeMatch[2] + boundAttributeSuffix + attributeMatch[3] +
          marker;
    }
  }
  html += this.strings[l];
  return html;
}

getHTML() method does conditional string concatenation based on the result of regular expression matching.

The definition of the regular expression (lastAttributeNameRegex) is like below.

export const lastAttributeNameRegex = /([ \x09\x0a\x0c\x0d])([^\0-\x1F\x7F-\x9F "'>=/]+)([ \x09\x0a\x0c\x0d]*=[ \x09\x0a\x0c\x0d]*(?:[^ \x09\x0a\x0c\x0d"'`<>=]*|"[^"]*|'[^']*))$/;

Since comment in the code explains this regular expression well, you can check it to understand what the regular expression represents.

In short, the following patterns are all valid attribute expressions.

 attr=value

    attr    =    value

    attr    =    
value

 attr="value"

 attr    =   'value'

 attr="value >>>

 attr='value `<>=>>>'

 attr='<!--

It will be difficult for most people to distinguish which part of the regular expression corresponds to which part of the actual string. To make it easier, I will show the matched parts with Named capture groups, which is a new feature of ES2018.

var string = `<div attr="<!--`
var regex = /(?<spaceBeforeName>[ \x09\x0a\x0c\x0d])(?<name>[^\0-\x1F\x7F-\x9F "'>=/]+)(?<equalSignAndValue>[ \x09\x0a\x0c\x0d]*=[ \x09\x0a\x0c\x0d]*(?:[^ \x09\x0a\x0c\x0d"'`<>=]*|"[^"]*|'[^']*))$/g
var result = regex.exec(string)

console.dir(result)
// =>
// [ 
//    ' attr="<!--',
//    ' ',
//    'attr',
//    '="<!--',
//    index: 4,
//    input: '<div attr="<!--',
//    groups: { 
//      spaceBeforeName: ' ',
//      name: 'attr', 
//      equalSignAndValue: '="<!--'
//    }
// ]

Now they became easier to distinguish, I think.

If the string matches the pattern, then lit-html combines the expressions with all the space characters before equal sign removed and .

html += s.substr(0, attributeMatch.index) + attributeMatch[1] +
          attributeMatch[2] + boundAttributeSuffix + attributeMatch[3] +
          marker;

// is actually...

html += '<div' + ' ' + 'attr' + '="<!--' + '{{lit-3958644673182541}}'

// and is finally...

html += '<div attr="<!--{{lit-3958644673182541}}'

What's Wrong

Now It is the problem that all the part after attr="<!--{{lit-3958644673182541}} could be parsed as comment.

When this is getTemplateElement() is called, the content of the HTML template element becomes empty because there seems no elements which have both of opening and closing tags.

This kind of string will finally throw an error when render function of the library is called (Of course I will explore this function later).

const value = 'value'
const templateResult = html`<div attr="<!--${value}>Error!</div>`

render(templateResult, document.body)
// => Uncaught TypeError: Failed to set the 'currentNode' property on 'TreeWalker': The provided value is not of type 'Node'.

Summary

So far, I learned the following points:

lit-html sometimes can't create a HTML string 100% accurately.
It is always good to wrap attribute values with quotations to avoid the cases.

In the next post, I will explore the reparentNodes function which is used by getTemplateElement() of SVGTemplateResult class.

Exploring How lit-html Works: TemplateResult and SVGTemplateResult constructors (2)

Nozomu Ikuta — Mon, 06 Jan 2020 14:58:37 +0000

In this series, How lit-html works, I will explore (not explain) internal implementation of lit-html.

In the previous post, we saw what TemplateResult and SVGTemplateResult look like, but I skipped some points.

In this post, I will explore Trusted Types API.

By the way, before writing this post, I found the official documentation that explains how lit-html works, which would be helpful if you want to grasp overview quickly.

But, I will keep reading code to expand my knowledge. This is why I put #devjournal tag on the posts of this series.

Trusted Types API

Trusted Types is an experimental API that makes it secure that DOM API, which by default can be sink of cross-site scripting (XSS).

It is obviously dangerous to allow users to assign a string to innerHTML property because they can let any valid HTML, even script element, be executed. Developers would say they don't do such a thing, but the more complicated the code gets, it becomes the more difficult to find the sinks.

Here is the place where Trusted Types API comes into play. With this API, all the insecure DOM API come to throws an error when a value is assigned, unless the value is created by createHTML method of a policy object.

elemenet.innerHTML = 'Some malicious Code' // Throw an error

In other words, it can be considered trustworthy that all the HTML string created by policy.createHTML(), unless the policy object is global or available to anyone.

lit-html convert HTML strings into ones that are treated as trusted by convertConstantTemplateStringToTrustedHTML() function, with policy whose name is 'lit-html'.

let policy: Pick<TrustedTypePolicy, 'createHTML'>|undefined;

function convertConstantTemplateStringToTrustedHTML(value: string): string|TrustedHTML {
  const w = window as any
  const trustedTypes = (w.trustedTypes || w.TrustedTypes) as TrustedTypePolicyFactory;
  if (trustedTypes && !policy) {
    policy = trustedTypes.createPolicy('lit-html', {createHTML: (s) => s});
  }
  return policy ? policy.createHTML(value) : value;
}

Available policy name can be restricted via Content-Security-Policy (CSP) HTTP directive so the attackers cannot create policy by themselves.

This is how lit-html makes itself a secure HTML templating library.

But, as I said in the previous post, Trusted Types API is available only when polyfill or browser run with flag for now. So convertConstantTemplateStringToTrustedHTML() function does nothing in most cases.

Summary

So far, I learned the following points:

All DOM API is by default insecure and sink of cross-site scripting
Trusted Types API is proposed to solve this issue, but is still experimental.
lit-html leverages Trusted Types API to make itself secure.

For further information about Trusted Types API, Google's blog post will be helpful.

In the next post, I will look into getHTML() method of the TemplateResult class in more depth.

DEV Community: Nozomu Ikuta

Vue RFCs: Changs on Global APIs and related things

Introduction

Self-contained apps

Problem

Solution

Tree-shaking support

Problem

Solution

APIs that are no longer supported

Summary

Change on study plan (2)

What I learned so far by writing 14 posts everyday

Pros

Cons

What I should do for better performance

Study Log: Reading Vue's RFCs (3)

Study Log: Reading Vue's RFCs (2)

Study Log: Reading Vue's RFCs

Change on study plan

How can I read source code and summarize them more efficiently?

Exploring How lit-html Works: render Function

render function

Searching Cache

Create a New NodePart

Rendering

WeakMap

Summary

Exploring How lit-html Works: TemplateResult and SVGTemplateResult constructors (4)

Recap of getTemplateElement() method of SVGTemplateResult class

reparentNodes function

Summary

Exploring How lit-html Works: TemplateResult and SVGTemplateResult constructors (3)

Handling Comment-Like Expressions in the Template Literals

What's Wrong

Summary

Exploring How lit-html Works: TemplateResult and SVGTemplateResult constructors (2)

Trusted Types API

Summary

`render` function

Create a New `NodePart`

Recap of `getTemplateElement()` method of `SVGTemplateResult` class

`reparentNodes` function