DEV Community: Giovane Cardoso

Vue.js in 2023 – Some tips you should know.

Giovane Cardoso — Wed, 21 Jun 2023 20:18:03 +0000

In next, I'll suggest many tricks to improve your experience with using Vue.js.

Vite + Unplugin

It's common to find developers who complain about the “verbosity” of the framework. However, when using Vite with a few more addendums, it is possible to shorten the syntax a lot, leaving the project much cleaner than what is normally found.

Below, a comparison between a common use with Vue 2 x an example using Vue 3+, Vite, unplugin-auto-import and unplugin-vue-components:

Common:

<template>
  <aside>
   <ComponentOne />
   <ComponentTwo />
  </aside>
  <main>
    <h1>{{ upper }}</h1>
    <ComponentThree />
    <ComponentFourth />
  </main>
</template>

<script>
import ComponentOne from './components/ComponentOne.vue'
import ComponentTwo from './components/ComponentTwo.vue'
import ComponentThree from './components/ComponentThree.vue'
import ComponentFourth from './components/ComponentFourth.vue'

export default {
  components: {
    ComponentOne,
    ComponentTwo,
    ComponentThree,
    ComponentFourth
  },
  props: {
     title: String
  },
  computed: {
    upper: function () {
      return this.title.toUpperCase()
    }
  }
} 
</script>

Reimagined:

<template>
  <aside>
   <ComponentOne />
   <ComponentTwo />
  </aside>
  <main>
    <h1>{{ upper }}</h1>
    <ComponentThree />
    <ComponentFourth />
  </main>
</template>

<script setup lang="ts">
const props = defineProps<{
  title: string
}>()

const upper = computed(() => props.title.toUpperCase())
</script>

Using unplugin-auto-import, keep attention in file names for don't override other .vue files. I recommend that you choose a structure that guarantees naming that will not cause conflicts.

Hooks

Decoupling methods using mixins has always been torture. However, with Vue 3 it is possible to use the API separately and reuse methods with ease:

export const useHook = () => {
  const data = ref('foo')

  const fn = () => {
    // ...
  }

  return { data, fn }
}

// in .vue file

<script setup>
const hook = useHook()

console.log(hook.data.value)
</script>

teleport

is a built-in component that allows us to “teleport” a part of a component's template into a DOM node that exists outside the DOM hierarchy of that component.

It's a very useful feature to reposition elements that are global or that need to be in another part of the tree at some point. A generic usage is to send an element to the root and position it absolutely:

<Teleport to="body">
  <UserInfoModal v-if="open" />
</Teleport>

Using a state manager (Vuex, Pinia) in conjunction with teleport enables greater control and reability of elements.

defineModel

Since Vue 3.3.x, it is possible to create material components and similar features.

Before, the common case is propping with modelValue and emitting the changed value to the top component, “simulating” a reactive prop:

Common:

<template>
  <input v-model="cmp" />
</template>

<script setup lang="ts">
  import { ref, computed } from 'vue'

  const props = defineProps<{
    modelValue: string
  }>()

  const emit = defineEmits(['update:modelValue'])

  const cmp = computed({
    get() {
      return props.modelValue
    },
    set(val) {
      emit('update:modelValue', val)
    },
  })
</script>

With defineModel:

<template>
  <input v-model="modelValue" />
</template>

<script setup lang="ts">
const modelValue = defineModel()
</script>

Simple, isn't it?

Nuxt 3

Nuxt it's a Vue framework that you probably know or have heard of. It is currently in a great phase, with a solid ecosystem due to the modules and with several features, that will surely add to your project.

VueUse

VueUse is a collection of essential vue composition utilities. It's a great choice if you're looking for ready-made solutions to common problems, and it can save you a good few hours of development.

Considerations

Vue.js is at it's your best when it comes to productivity and used concisely, it has everything to add to your work (and please don't rewrite an entire system just because of these tips). Thanks for reading!

UnunuraCSS - How I Built "my own TailwindCSS"

Giovane Cardoso — Wed, 17 May 2023 19:23:42 +0000

If you don't know, TailwindCSS is a CSS framework with the aim of providing classes for primary use.

UnunuraCSS, means "unique" in Esperanto (individual or unmarried, depending on the context, but that's beside the point), got its name because every class generated by framework is totally unique and not supported by other classes. Its main objective is to offer an alternative with more build-in functionalities, a shortened syntax and more practical configurations:

// Example in Tailwind
class="text-2xl text-white font-roboto font-bold flex flex-col flex-wrap align-center justify-between"

// Example in Ununura
class="text[3rem white roboto 700] f[col wrap ai-center jc-between]"

But, how did I build?

On-Demand

The main inspiration for this framework is UnoCSS and his article Reimagine Atomic CSS. Before reading the article, I recommend knowing more about UnoCSS and its philosophy.

Its main idea is to generate CSS on demand, which is basically to inspect all possible classes of an ecosystem as a whole, create the scope of the given classes according to the necessary specifications, and insert them into a single global .css file or the SFC (Single File Component) of the read file depending on the framework.

For example, we have the following case:

// index.html
<aside class="text-bold-and-large other-class-here">
// ...
</aside>

text-bold-and-large can be a manually declared class in any CSS file, like:

.text-bold-and-large {
  font-weight: 700;
  text-size: 1.5rem;
}

But the point of UnunuraCSS is to build a specification IF it exists, that is, it is not a common class, and that it is valid, respecting the following sequence:

Read all files that may or may not have CSS classes;
If any, transform the appropriate sequence to a new specification;
Transform the title to a nomenclature supported by CSS 3 and convert your template in the pre-processing of each file;
Generate a global CSS with the generated classes that cannot be inserted in the same file.

This sequence is executed thanks to Vite, which by following the Rollup specification, it is possible to do these tasks in a simple plugin:

return {
  name: 'ununuracss:core',
  enforce: 'pre',
  async transform(code, id) {
    if (!filter(id)) return

    if (isVueFile(id)) {
      return { code: await UnunuraScopedSFCFile(code, 'vue') }
    }

    if (isSvelteFile(id)) {
      return { code: await UnunuraScopedSFCFile(code, 'svelte') }
    }

    // ...
  },
  resolveId(id) {
    return id === VIRTUAL_CSS_INJECT_FILENAME ? RESOLVED_VIRTUAL_CSS_INJECT_FILENAME : null
  },
  async load(id) {
    if (id === RESOLVED_VIRTUAL_CSS_INJECT_FILENAME) {
      const code = await UnunuraGlobalGenerate(ununura)

      return { code }
    }
  },
  async handleHotUpdate({ server, file }) {
    if (filter(file)) {
      await reloadServer(server, ununura)
    }
  },
}

enforce: It will be executed before all other rollup plugins and in the pre-processing stage, that is, before any transformation performed by internal instances or other rollup plugins.

transform: Receives the file content (code) and the file path (id). Our objective in this step is to execute what is necessary for each type of file and its support (.vue, .svelte, .jsx...), ignoring files that cannot have classes (or Ununura does not offer explicit support) and converting to a new template. As Ununura does not use the default className titles (explained in Key-Resources), here is also the implementation of the new titles.

resolveId: Resolve \0, recommended by Vite, for creating a virtual CSS file (ununura.css). All other id's are ignored.

load: The creation of ununura.css file and the classes that will be globally in the application.

handleHotUpdate: Every change in a valid file, that is, which may have had a CSS change, is triggered and the virtual CSS is rewritten:

export const reloadServer = async (server: ViteDevServer, options: UnunuraCoreOptions) => {
  const virtualModule = server.moduleGraph.getModuleById(RESOLVED_VIRTUAL_CSS_INJECT_FILENAME)

  if (virtualModule) {
    await server.reloadModule(virtualModule)
  }
}

Because everything runs in pre-processing time, it is not necessary to deal with each library (such as using @vue/compiler-sfc), it is only necessary to respect the specification of each SFC.

AST

To search for classes, a deep-first search is done in the syntax abstraction tree from all valid files, fetching the className and class attribute by default from embedded HTML's:

export const classesFromRawHtml = (html: string, adapters?: string[]): UnunuraASTNode[] => {
  // ast from rehype package
  const tree = fromHtml(html, { fragment: true })
  const classes: UnunuraASTNode[] = []

  const insert = (node: any, cl: string, flag?: string): UnunuraASTNode => ({
    tag: node.tagName,
    class: cl,
    position: node.position,
    flag,
  })

  const ast = (children: Content[]): void => {
    children.forEach((node) => {
      if (node.type === 'element') {
        if (node.tagName === 'template') ast((node.content as Root).children) // .vue sfc

        adapters?.forEach((adapter) => {
          if (node.properties && node.properties[adapter]) {
            classes.push(insert(node, node.properties[adapter]))
          }
        })

        const target = node.properties?.className?.join(' ')

        if (target) {
          classes.push(insert(node, target))
        }

        if (node.children) ast(node.children)
      }
    })
  }

  ast(tree.children)

  return classes
}

Certain files have adapters to run the classes without the need for a runtime. For example, Ununura supports the :class=[...] of .vue in both ternary and object format. If needed, a separate runtime is also offered.

DFS is not one of the best alternatives, but if you're not the type of programmer who writes a .vue over 3000 (three thousand) lines of code, it won't be a problem in development mode (much less in development mode). production, as the build time is practically instantaneous).

Certain specifications use means other than AST, such as .[jt]sx using @babel/parser.

A general buffer is used for the registration of all classes and a temporary buffer for the registration of the classes of each attribute, where this temporary buffer is used for the verification of unique keys by each attribute and the creation of rules , such as responsiveness and custom themes.

Key-Resources

Unlike standard CSS classes, Ununura transforms the following two definitions:

Key-Unique Resource: class="flex:col text:white"
Key-Multiple Feature: class="flex[col wrap] text[white 1.1rem]"

As you can see, these two shapes are not supported by default by CSS. So, in addition to the tool having to create the CSS given its key, which indicates the group it belongs to, and given its resources, which say what the key actually is, it is necessary to convert each key-resources to a title " minified" (slug):

flex:col -> .flex-col 
text:white -> .text-white 

flex[col wrap] -> .flex-col-wrap 
text[white 1.1rem] -> .text-white-11rem

Internally, all classes are generated to follow the concept of Only Scoped, where every class generated in the same application (disregarding micro-frontend federations), being totally unique in its selectors, such as @media, will not be affected by other contexts, where in each title the current line of className and the name of the referenced file are also inserted. For example:

flex:col -> .flex-col -> .flex-col-1-app
text:white -> .text-white -> .text-white-1-app

flex[col wrap] -> .flex-col-wrap -> .flex-col-wrap-2-app 
text[white 1.1rem] -> .text-white-11rem -> .text-white-11rem-2-app

Because it is not valid at runtime, it was necessary to create a simple lexer to differentiate the spacing of each class with the spacing of each resource.

Not all supporters have the same idea, where some keys in particular can take advantage of the resource space to use as a sequence, and even incorporate other supporters in themselves, as is the case with the gradient:

class="gr[90deg rgba-200-200-200-0.5 0% rgba-100-200-0-0.35 30% rgba-255-100-50-0.8 100%]"

Each key can have more than one variation, like text-font, flex-f, rounded-r, ...

As it is possible to have a virtual .css file, it is possible to insert classes and pre-definitions without the need to be treated in the common flow, such as having the functionality to "reset the css" in the class:

class="reset:meyer ..."

/* ununura.css */
/* http://meyerweb.com/eric/tools/css/reset/ 
   v2.0 | 20110126
   License: none (public domain)
*/

html, body, div, span, ... {
    margin: 0;
    padding: 0;
    border: 0;
    font-size: 100%;
    font: inherit;
    vertical-align: baseline;
}

/* ... */

Supporters

To validate each resource and its proper context, a system of supporters is used, where each resource is classified in different ways by each key:

export const getResourceText = (
  identifier: UnunuraIdentifier,
  ctx: UnunuraGenerateContext
): string => {
  const color = getSupportedColor(ctx)
  const fontSize = getSupportedFontSize(ctx)
  const fontFamily = getSupportedFont(ctx)
  const fontWeight = getSupportedFontWeight(ctx)

  let setter = setterHead(ctx)
  setter += setterRow(color, `color: ${color}`, ctx.contents)
  setter += setterRow(fontSize, `font-size: ${fontSize}`, ctx.contents)
  setter += setterRow(fontWeight, `font-weight: ${fontWeight}`, ctx.contents)
  setter += setterRow(
    fontFamily,
    `font-family: ${getFontFamilyCallback(`\'${fontFamily}\'`, ctx?.ununura?.defaults?.values?.fontStack || DEFAULT_FONT_STACK)}`,
    ctx.contents
  )

  return resolveCssClass(identifier, setter, ctx)
}

Supporters can infer rules by default, like the case of the unit supporter which, in the absence of a unit, it suffixes px and multiplies the numerical value by 1.0 (this can be overridden in the settings):

class="w:100% md(w:768)" -> class="w:100% md(w:768px)"

Each supporter can accept different resource bases, like color which accepts several ways to enter a color, or fontFamily which accepts default browser fonts and fonts extended by configuration file:

class="bg:rgb-255-200-0 text:red"
class="font:arial"

// with extended configuration
class="bg:primary text[arial primary 1.2rem]"
class="font:roboto"

Even though every resource search is O(n), a key will hardly have more than 10 (ten) resources.

Context

In addition to the default context, it is possible to infer specific rules using () as the attached context:

class="text:white md(text:black) dark(text:black md(text:white))"

Because of validation by the temporary buffer, all keys in default context have to be inserted at the beginning.

class="md(hover(dark(xl(active(light(xl(focus(sepia(bg:rgba-0-0-0-0.1))))))))" is valid, but each context group is resolved only once, that is, in this case only md, hover and dark will be considered rules. It would be nice, but it is not practical to have more than one specific group for identical context rules.

Globals

Globals are special resources that every key has access to, serving as a helper when generating your class, such as:

text[! red] -> color: red !important;

flex[? flex-1] -> Removes display: flex;

before(grid[content-a_some_test col-3 ...]) -> content: "a some test"

Runtime

As mentioned in the AST section, the framework provides a runtime, which is basically a MutationObserver that recompiles the classes if necessary:

const MO = new MutationObserver((list, _observer) => {
  const targets: Element[] = []

  list.forEach((item) => {
    if (item.type === 'childList' && item.target !== injectStyle) {
      item.addedNodes.forEach((node) => {
        if (!node) return

        const _node = node as Element

        if (!_node?.className) return

        targets.push(_node)
      })
    } else if (item.type === 'attributes') {
      if (!item.target) return

      const _node = item.target as Element

      if (!_node?.className) return

      targets.push(_node)
    }
  })

  generate(targets)
})

MO.observe(defDocument.documentElement || window.document.body, {
  childList: true,
  subtree: true,
  attributes: true,
})

The runtime is not coupled to avoid compatibility problems with the post-processing of each project, having to be inserted individually by the ununura-runtime package.

Extra

The engine offers other features, such as integration with PostCSS, CLS Fallback with FontaineCSS, use of Modern Font Stack, styles for syntax customization, malleable configuration, support for other frameworks like Nuxt and Astro, among other features.

The project is fully open source, and if in doubt, see the documentation.

Did you like the article? Consider using the tool in some project, I guarantee you will like it :)

How I Built a 100% Client-Side Word Processor

Giovane Cardoso — Wed, 17 May 2023 19:19:47 +0000

After launching version 1.1 of betterwrite.io (and probably the last major one), deciding to write on a trajectory that lasts for almost 2 (two) years and which may last longer.

Warning from before that this project is not an example of software architecture, given its many technology changes, features that have been completely removed, forgotten or built without use; typos, dubious decisions and missed conversations.

Treat the word processor as a mere project for personal use, built by just one person and gone further than it should have. So, you won't be annoyed by the following review.

A Word Processor Focused on Creative Writing

The idea came up during the peak of the COVID-19 pandemic, where I divided my time between freelances without much desire and procrastination in the sheer boredom of social isolation.

Without further details, the idle time made me want to continue or start something personal that might or might not be useful for my work, but one factor was decisive for choosing a project that involved both programming and writing: the slowness of Google Documents.

The Cursed Canvas

As much as there are other considerably good options on the market, such as Microsoft Word, Overleaf, thousands of WYSIWYG editors that transform markdown into PDF and even notepad++, at the end of the day, being hostage to practicality and tools from Google Docs was a daily action.

But a problem was recurrent: When surpassing about 100 (one hundred) pages with large paragraphs and color and spacing customizations, the editor was considerably slow and required me to separate the project into other files and join them only at the end.

Consisting of a single canvas, all manipulation, and transformation depends on it, which means that even what is not being displayed is being considered valid in the context. Treating as a unit, not as a block, has its advantages, such as free customization and extensibility, but inserting a line break, page break or changing text positions shouldn't be costly.

These difficulties, added to the fact that practically all extensions (which considerably improve the editor as a whole) broke every release (like the beloved Dark Theme) made me decide: build my own or continue an existing project that was precisely what I wanted.

Obviously Google Docs is much more robust than Betterwrite, in addition to being generalist. Comparing them directly doesn't make much sense, as they have completely different focuses (and investments).

Fontaine Editor — A modern, multi-platform manuscript editor.

An initiative of this scale is a difficult idea to take seriously, especially when whoever is building the tool has already had several projects abandoned for several different reasons, but when finding Fontaine I ended up changing my opinion a little.

Fontaine consisted of a manuscript editor and provided control tools and an easy-to-use interface. However, the project was stopped, and its status did not allow me to use it due to the lack of document export.

Having it discontinued unfinished was a clear negative sign, but its simplicity in displaying relevant information, even though it was not of a high level of complexity, gave me enough courage to start a project with Vue 2, Vite, Typescript, PDFMake and TailwindCSS.

MVP

The above version, v0.1.2, was the first versioned (recovered for this, thanks git tag) and developed relatively quickly (rushing), consisting of a block editor where each line was a <textarea /> that barely worked properly, a cloud save with a .json via the SDK of Dropbox (one of features removed), shortcuts for each sidebar item (also removed), a list of chapters and the dreamed PDF generator.

Event System

Firstly, the entire logic of the application consists of issuing events anonymously and carrying out each job individually. Using mitt for this, all events of a given set (currently called plugin) are registered by a key and called even though they are not inside a setup().

Registered plugins have access to stores (pinia stores) and vue hooks, making it possible to decouple each functionality and facilitate maintenance.

The following is the flow of the PDF:

export const PDFPlugin = (): PluginTypes.Plugin =>
  createPlugin({ name: 'pdf' }, [PluginPDFBase, PluginPDFSet])

// ...
const PluginEntityInputInitial = (
  emitter: PluginTypes.PluginEmitter,
  content: PluginTypes.PluginContentOn
) => {
  emitter.on(
    'plugin-input-watch-initial',
    (item: PluginTypes.PluginLoggerDefault) => {
      if (!item.data) return

      const created = content[0]

      created && created(item)
    }
  )

  // ...
}

// in pdf monorepo
On.externals().PluginPDFGenerate(emitter, [
  (options: PDFDocOptions) => {
    // ...

    hooks.storage.normalize().then(() => {
      create(options)
    })
  },
  () => {},
])

// App.vue
<template>
  <router-view></router-view>
  <PWAPrompt />
</template>

<script setup lang="ts">
  import { useStart } from '@/use/start'
  import { ThemePlugin } from 'better-write-plugin-theme'
  import { ImporterPlugin } from 'better-write-plugin-importer'
  import { PDFPlugin } from 'better-write-plugin-exporter-pdf'
  import { DocxPlugin } from 'better-write-plugin-exporter-docx'
  import { TxtPlugin } from 'better-write-plugin-exporter-txt'
  import { HtmlPlugin } from 'better-write-plugin-exporter-html'
  import { AnnotationsPlugin } from 'better-write-plugin-annotations'
  import { EpubPlugin } from 'better-write-plugin-exporter-epub'

  useStart([
    ThemePlugin(),
    ImporterPlugin(),
    PDFPlugin(),
    DocxPlugin(),
    EpubPlugin(),
    TxtPlugin(),
    HtmlPlugin(),
    AnnotationsPlugin(),
  ]).init()
</script>

As you can see, this system enabled the migration to mono-repositories, using turborepo and lerna to adjust the flow and enable the decentralization of internal packages.

The PDF Generator

Speaking of the generator, it implied 10 (ten) mb of .tff in the bundle and had an unbearable bug when attaching external sources (and which continued for a long time), which consisted of not allowing the use for being a readonly method and that made its customization usable only in a development environment. However, it was (and still is, as it has not been completely rewritten) useful to me.

At the time I didn't know about skipTsLibCheck.

pdfeasy was built to replace pdfmake, but since pdfmake received updates that tweaked the most of the problems ended up being maintained.

The other generators implemented follow a flow very similar to that of the PDF.

Model-Entity

As much as it has undergone severe changes in the new versions, the concept is the same: a list of entities, and each entity consists of blocks of different types such as paragraphs, list, image, line/page break, among others.

<template>
  //...
  <EditorEntityDefault
    v-for="(element, index) in CONTEXT.entities"
    :id="`entity-${index}`"
    :key="index"
    :entity="element"
  />
  // ...
</template>

Its big difference to block-style editors is that each event is emitted individually, and each event entry is triggered only when needed.

For example, text blocks do not use Vue's v-model, explained in this file, where the value of each el.innerHTML (new blocks use contenteditable in place of <input />) is computed only when a newline is added or another chapter is loaded.

await storage.normalize()

// ...
const setData = (val: string) => {
  input.value.innerHTML = val
}

const save = (target: number, raw: string) => {
  if (raw === null) return

  CONTEXT.entities[target].raw = raw
}

It may seem like a silly approach, but this allows massive bodies of entities being rendered in the same chapter to have fluid typing in text entries, which is a common problem in WYSIWYG editors.

The display sidebar is only changed when a block needs to be updated, which is a limitation of this approach, but something to overlook.

The list uses the key-index of the list itself for each entity to infer which block is at the front or back in O(1), such as adding an extra empty line after a page/line break or for deleting multiple items.

The find/replace text uses a different list view as it has a different view proposition:

<template>
  <EditorBaseRenderFinder v-if="ABSOLUTE.shortcuts.finder" />
  <EditorBaseRenderSwitcher v-else-if="ABSOLUTE.shortcuts.switcher" />
  <EditorBaseRenderDefault v-else />
</template>

<script setup lang="ts">
  import { useAbsoluteStore } from '@/store/absolute'

  const ABSOLUTE = useAbsoluteStore()
</script>

Other features follow a similar philosophy, such as the annotations markdown editor that uses debounce time to save changes and automatic saving that only occurs in case of context destruction:

// annotations monorepo
const fn = hooks.vueuse.core.useDebounceFn(doc => {
  setFile(file.id, doc.toJSON())
}, 500)

// editor.ts
const inForcedSave = async () => {
  if (EDITOR.configuration.autosave) {
    await storage.normalize()
    await local.onSaveProject(false)
  }

  if (EDITOR.configuration.cloudAutosave && online.value) {
    await cloud.saveProject()
  }
}

useEventListener('beforeunload', async () => {
  await inForcedSave()
})

onBeforeRouteLeave(async () => {
  await inForcedSave()
})

100% Client-Side

Betterwrite has a simple concept as an application: only static files, that is, without the need for SSR. This is only possible due to the polyfills that allow the import and generation of documents using the API of the browsers themselves. By Vite, node-stdlib-browser was used to accomplish this task:

import inject from '@rollup/plugin-inject'
import { Plugin } from 'vite'

export const viteStdlib = (): Plugin => {
  return {...inject({
    global: [
      require.resolve(
        'node-stdlib-browser/helpers/esbuild/shim'
      ),
      'global'
    ],
    process: [
      require.resolve(
        'node-stdlib-browser/helpers/esbuild/shim'
      ),
      'process'
    ],
    Buffer: [
      require.resolve(
        'node-stdlib-browser/helpers/esbuild/shim'
      ),
      'Buffer'
    ]
  }),
  enforce: 'post'
}}

As the word processor uses most polyfills, it turns out to be worth injecting them all at once.

Another important point is the migration of the SDK from Dropbox to Supabase, which made it possible to authenticate users and save the project in the cloud safely on the client-side.

Even the word processor, being static, is hosted for free. Thank you Vercel!

If you want more information about 100% Client-Side, see the application's technical documentation.

The Progress

When I decided to go ahead with this project, I made some drastic changes that (feel) paid off.

To validate the editor and his idea, some book would have to serve as a guinea pig, and that is why Restos da Geada - Entre Plano was chosen. Self-publish, being my first book released in my name that was completed, consequently gave me the freedom to do whatever I wanted with the editor (like losing paragraphs due to editor error without fearing deadlines). It was started in Google Docs, but was migrated to Betterwrite, having its project initialized in v0.0.1.

A war survivor, he was responsible for compatibility between versions, the need for authentication, all the features focused on creativity and the ability to place images on break lines.

A curious fact is that support for importing in other extensions only existed in v0.10, so a copy-paste of raw HTML between blocks exclusively for this task was implemented, feature also removed .

Another curious fact is that your project was lost in a test in production, but it was recovered in an old locally saved project (.bw) and its values were copied from .json by hand.

Electron

Before adopting PWA, Electron was implemented almost completely (with support to other operating systems and automatic updates), but due to some limitations of Vue (and the Vite plugin) it was decided to "throw out" the entire implementation and make room for a hybrid application.

The PWA went hand in hand by allowing caching in service-worker certain requests (gstatic) and required files (a .ttf font for pdfmake and a typeface font used by *threejs * on the landing).

WindiCSS

The project was migrated from TailwindCSS to WindiCSS due to the delayed release of TailwindCSS 3.0, with HeadlessUI being a big part of material design. The hot-reload saved me hours in development mode.

A migration to a proprietary Atomic CSS lib almost occurred, but the process was paused.

Bundle Size

The size of the final application was never of great concern, but when migrating to PWA, the loading time was drastically off the curve (negatively).

It is currently acceptable for your proposal, but it can be improved.

The actual cache can reach up to 20 (twenty) mb depending on usage.

1.1

Its major version has been released, but 1.1 is the true stable version, fixing chronic application problems and bringing with it the editor's true initial objective: the focus on creativity.

Desenvolvimento de Jogos para Programadores(as) WEB - Parte 1

Giovane Cardoso — Tue, 23 Feb 2021 14:46:23 +0000

Sumário

Introdução
Game Loop
Tick
UI
Ciclo de Vida
ECS
Informações Adicionais
Parte 2 - PixiJS

Introdução

Neste artigo vamos buscar trazer a familiarização com DOM a forma que jogos funcionam internamente, assim conseguindo relacionar conceitos que um desenvolvedor(a) WEB possui com o que está sendo proposto.

Este artigo é recomendado para desenvolvedores(as) que possuem um bom conhecimento de DOM e sobre gerenciamento de estado, mas nada impede de seguir os exemplos já que tem muitos link's auxiliares :)

Game Loop

Os loops de jogo são o exemplo perfeito de um padrão de programação para jogos. Quase todo jogo tem um, e relativamente poucos programas fora dos jogos os usam.

Podemos fazer um paralelo entre os loop's convencionais com os Event Listeners do DOM, onde sempre estão esperando uma alteração para emitir um evento:

Loop convencional:

while (true) {
 InstanceManager.escutarComando(InputManager.carregarTeclado());
}

InstanceManager: Seria o gerenciador responsável pela instância atual da aplicação e do que está sendo exibido. Nele poderíamos acessar a vida de um jogador, o tempo atual de jogo e os itens que estão no mapa, por exemplo.
InputManager: Seria o gerenciador responsável pela captura e emissão de dados que o sistema recebe, como por exemplo a entrada de dados do teclado/mouse.

DOM:

document.addEventListener('keydown', (event) => {
  dispararTeclado(event.keyCode); // ou event.key
});

Com um Event Listener, conseguimos escutar eventos a qualquer momento e realizar o que queremos de forma separada, sem a necessidade de um loop fixo.
Nos exemplos iremos utilizar apenas JavaScript para melhor compreensão da semântica.

Tick

Você deve ter se perguntado: Se este loop não está bloqueando a entrada, o quão rápido ele gira? A Cada volta no loop o estado do jogo avança em alguma quantidade, chamamos isso de tick.

Podemos fazer um paralelo diretamente com FPS(Frames por Segundo). Por exemplo, se um jogo estiver renderizando 60 "fotos" por segundo, quer dizer que, no melhor dos casos, temos o nosso loop sendo percorrido a 60 ticks por segundo.

É importante ressaltar o frame-time, que é o tempo normalmente contado em milissegundos entre a demora de renderização de um frame a outro, normalmente não é 100% exato. Por exemplo, podemos ter um jogo em que o frametime é alto devido a placa de vídeo em não conseguir renderizar a tempo a qualidade das texturas, ou o processador não conseguir calcular a ação de todos os sprites a tempo. Normalmente game-engines possuem recursos para normalizar esse tipo de situação.
Se quiser entender um pouco mais afundo sobre frame-times, recomendo este fórum.
No JavaScript, faz mais sentido em utilizar setInterval() do que o while para executar estes loops, assim garantido um tickrate "esperado".

UI

Para o terror dos backend de plantão, "a regra de negócio dos jogos é feita no lado do cliente", e a interface é executada durante o tick, recebendo apenas as novas informações (se tiver) para renderizar alguma coisa.

As ferramentas gráficas modernas de construção de interfaces para jogos ficam "parados" até receber algum evento:

Loop tradicional:

while (true) {
  const evento = esperandoEvento();
  if(evento?.keyCode == 73) { // Se o evento retornar algo, verifica se a tecla 'I' do teclado foi pressionado
    InstanceManager.renderizarInventario(); // Irá renderizar o inventário pelo tick atual, se o usuário parar de pressionar, o inventário é fechado.
  }
}

DOM:

document.addEventListener('keypress', (event) => {
  const inventario = document.getElementById(event.target.id);
  event.keyCode == 73 ? document.body.appendChild(inventario) : inventario?.remove(); 
  // Se a tecla 'I' for pressionada, adicionamos o inventário ao DOM, ao contrário, retiramos do DOM se ele estiver sendo renderizado.
});

Se quisermos que o inventário seja renderizado até o usuário fechar manualmente, deixamos um booleano true quando keypress for acionado, e false quando keyup for acionado.
Os teclados possuem uma "trava" por padrão, esperando um tempo após o evento de pressionar para acionar outros eventos de 'keydown'. Podemos burlar da mesma forma do evento acima, usando um booleano. Em game-engines já temos este problema solucionado, agora para jogos na web as lib's Pixi.js e P5.js também possuem formas internas de evitar este problema.
Neste site, podemos encontrar o keyCode de cada tecla de uma maneira facilitada.
keyCodes não são padronizados, seja de navegador para navegador ou de sistema para sistema, recomendo fortemente em que procure a melhor forma de criar seu sistema de escuta.
É possível construir UI para jogos com HTML e CSS? Sim! Uma das grandes tecnologias do mercado e utilizada pelas empresas como Riot Games (VALORANT), Ubisoft (The Division), entre outras, é feito com HTML/CSS/C++. Por mais que seja uma tecnologia "á encomenda", temos a opção do Ultralight, também sendo HTML/CSS/C++.

Ciclo de Vida

Os loop's precisam possuir um padrão de código a ser executado, para evitar verificações dessincronizadas e a exibição de itens incorretamente. Para jogos em real-time, essa diferença pode parecer ser minúscula, mas para jogos por turno, por exemplo, pode causar de renderizar algo que sequer existe no contexto.

A seguir temos a forma padrão utilizada e que é recomendada:

Por Imagem:

Por Código:

while (true) {
  entradaDeDados();
  atualizar();
  renderizar();
}

entradaDeDados(): Aonde seria escutado a entrada de ações externas, como teclado e mouse. No DOM, não teríamos necessidade de colocar dentro de um loop, como mostrado no começo do artigo.
atualizar(): Aqui seria realizado todas as "regras de negócio" internas, como se o jogador levou dano, se um item foi adicionado no mapa, etc. Aqui também podemos realizar requisições HTTP e a serialização de dados.
renderizar(): irá buscar se possui novas informações, se não, continua renderizando as antigas informações.

ECS (Entity Component System)

Traduzido diretamente como Sistema de Componente e Entidade, é a forma que game-engines guardam e fornecem informações reativas para os nossos jogos. Na WEB são os Gerenciadores de Estado (Vuex do Vue, Redux/MobX do React), por seguirem a ideia de Pub/Sub.

Fluxo do Vuex:

Fluxo de um ECS Genérico:

No JavaScript, temos um ECS simples chamado de Ensy, e um criado para React.js, mas longe de ser o ideal. Devido a isso, para jogos HTML5 se tem a necessidade de criar a própria logística interna. WebAssembly pode ser uma boa alternativa para conseguir utilizar um ECS robusto.

Informações Adicionais

Os Ciclos de Vida de um jogo padrão se comparado ao DOM pode mudar drasticamente dependendo da implementação desejada.
Se tratando de jogos HTML5, por mais que temos os WebWorkers, JavaScript continua sendo single-thread, limitando a forma que podemos tratar eventos e a quantidade de sprites a serem computadas.
Realizar requisições HTTP sem paralelismo pode ser um problema bem grande, principalmente se estiver no loop.

Parte 2 - PixiJS

Ainda não está disponível :(

Este artigo foi escrito por Giovane Cardoso. Twitter - Github