mirror of
https://github.com/akvorado/akvorado.git
synced 2025-12-11 22:14:02 +01:00
52816e7fe1
I thought it would be easier!
TypeScript typing is a bit different than Python one. Mostly, I think
that because JavaScript did not have named arguments, libs tried to be
smart by allowing polymorph arguments, the typing system has to be
powerful enough to handle complex conditions. However, sometimes, it's
quite complex to express things and sometimes, this can be a bit
buggy (many issues on GitHub about that). For example, you can narrow a
type with "if" and "switch", but for the later, you can't have several
cases for the same body. However, the ternary operator does not allow to
narrow the type. Moreover, in functional programming, lambdas are often
used but because TypeScript is not smart enough to know if a callback is
executed immediatly, it cannot assume the previous narrowing of a type
is still valid inside the lambda.
Also, eCharts typing is quite difficult because it accepts objects with
many different types. Without TypeScript, you know that you will get one
specific form, but with TypeScript, you need to either force or
enumerate cases you won't have. Moreover, the types are not all exposed,
so you have to dig them inside the `d.ts` files.
Another difficulty is that Vue 3 LSP server ("volar") does not work like
the one for generic TypeScript. In Emacs, it does not provide
information automatically in the modeline. Also, I did not find a way to
expand a type. Sometimes, it just says that a variable is
SomeRandomType, but you need to lookup yourself what could be
SomeRandomType. When there are errors, TypeScript does a good job to
explain where the incompatibility is. However, the errors are quite
verbose and the end is the most interesting hint. I suppose the LSP
server could have a condensed version of the error message ("options →
tooltip → formatter should be type X, not type Y") to help.
Emit signals are also not typed on the destination component. I don't
know if this is expected.
The migration has two benefits:
1. the code should be more robust (still not tested, but types are a
great help to catch problems)
2. the values sent from one component to another are now correctly
specified (previously, `console.log` was heavily used to check that we
get what we want) and I can use `null` when I don't have a value instead
of using an empty object and putting question marks everywhere
16 lines
367 B
JavaScript
16 lines
367 B
JavaScript
// SPDX-FileCopyrightText: 2022 Free Mobile
|
|
// SPDX-License-Identifier: AGPL-3.0-only
|
|
|
|
/** @type {import('tailwindcss').Config} */
|
|
module.exports = {
|
|
content: ["./index.html", "./src/**/*.{vue,js,ts,jsx,tsx}"],
|
|
darkMode: "class",
|
|
theme: {
|
|
extend: {},
|
|
},
|
|
plugins: [
|
|
require("@tailwindcss/typography"),
|
|
require("@headlessui/tailwindcss"),
|
|
],
|
|
};
|