Pull to refresh
25
0
Alexey Schebelev @AlexxNB

Fullstack Javascript

Send message

Ubuntu 23.04 поставилась как родная, все устройтсва работают из коробки. Кроме санера отпечатков, на него драйверов вроде нет: ID 2808:9338 Focal-systems.Corp FT9201Fingerprint.̚

Конечно, не всем будет достаточно 8 Гбайт оперативки (тем более что в моделях F+ Flaptop она не расширяется).

Расширяется, и не просто расширяется - там два полноценных слота под память и один свободен во всех модификациях.

Репортили вроде этот баг установщика давно, странно что не исправляют.
Выбирайте английский язык при установке, в системе потом можно поменять на русский при необходимости.

Найс, тогда я погляжу еще внимательнее. Все порываюсь переписать svelte-docs, там такой парсер очень нужен.
Можно сделать CLI поверх sveltedoc-parser, который при запуске в папке проекта, по полю "svelte" в "package.json" нашел бы компонент(или компоненты, если это библиотека), и нагенерил этот index.ts.d =)

JSDoc хорошо использовать "для себя" внутри подкомпонентов для подсказок в IDE, но наружу, в переиспользуемом компоненте, все же лучше руками написать index.d.ts, поскольку там обычно все несколько сложнее, чем просто описание пропсов. Например, там еще может быть описание переменных которые получаются из слота, либо какие-то, кастомные типы и интерфейсы. Врятли это получится нагенерировать автоматически.
PS: почитал про sveltedoc-parser — они уже значительно развитее, чем я смотрел последний раз. Может и получится сделать генератор.

JSDOC в Svelte-комопнентах не пользуется особой популярностью, т.к., например, в ES6 модуле он скорее всего будет утрачен при компиляции. Полезнее создать index.d.ts файл в папке проекта(пакета), где описать какие пропсы экспортирует компонент. Этот файл подхватится IDE и будет давать подсказки независимо используется ли модуль или голый компонент svelte. Ну и те, кто пишет на typescript смогут использовать ваш комопнент полноценно, с типами.


Например для комопонента часов из статьи файл index.d.ts будет иметь примерно такой вид:


export default class {
    $$prop_def: {
      /**
       * Color of sign
       * @default "white"
       */
      color?: string;

      /**
       * Card background color
       * @default "black"
       */
      background?: string;

      /**
       * Border color
       * @default "grey"
       */
      border?: string;
    };
  }

Подумал, все-таки исправил по вашему совету, только, кажется, уместнее написать "svelte": "3.x".
Но, к сожалению, проблему более вероятную это все равно не решит, 3.1 от 3.30 скорее всего отличается тоже(не могу точно сказать) по работе с штуками из "svelte/internal". Если начнутся проблемы с совместимостью, то лучше импортировать модуль IIFE по полному пути с небольшой оберткой. И смириться что в проекте возможно будет забандлено два свелта. А еще лучше кинуть исуса автору пакета, чтобы он обновил его для работы с актуальной версией.

Аналогично в Vue. Пример тут.


<template>
  <SvelteClock color="gold" />
</template>

<script>
import toVue from "svelte-adapter/vue";
import Clock from "svelte-clock-demo";

export default {
  components: {
    SvelteClock: toVue(Clock),
  },
};
</script>

В общем, как ни крути, а заголовок статьи с преувеличением — кому-то все таки больно может и быть =)

Вероятность того, что где-то будет собираться новый проект на Svelte2 стремится к нулю. Можно там указывать версию(скопировать с соответствующего поля в devDependency), поскольку даже в текущих версиях возможны вариации, но это может привести к тому, что те кто будут использовать комопонент импортируя из "svelte" поля(а таких большинство), получат, что скомпилированый компонент будет импортировать фунции из другой версии Svelte, что может вызвать проблемы, поскольку получится, что у каждого компонента своя версия рантайма, что может конфликтовать(я сталкивался).
Со звездочкой в peer-зависимости аналогичные проблемы возможны у тех кто использует ES6 модули. Но скорее всего, ничего страшного пока не будет, рантайм фреймворка останется в единственном экземпляре, даже если несколько компонентов будут использовать.

Лучше всего воспользоваться специальным адаптером(он же подойдет и для аналогичного встраивания в Vue).


Тогда код получится таким(см. пример на Codesandbox):


import React from "react";
import ReactDOM from "react-dom";
import toReact from "svelte-adapter/react";
import  Clock from "svelte-clock-demo";

const SvelteClock = toReact(Clock);

const App = () => {
  return (
    <div>
      <SvelteClock background="white" color="black" />
    </div>
  );
};

ReactDOM.render(<App />, document.getElementById("root"));

Малина — компилируемый фреймворки(аналогично Svelte). На выходе для каждого компонента там создается некоторое количество бойлерплейта обслуживающего стейт, реактивность и прочее. Т.е. нужно понимать, что если хочется вынести кусок шаблона в отдельный компонент, то это не будет просто кусок шаблона в бандле, а полноценный код компонента со всем этим бойлерплейтом. Фрагмент решает эту проблему, когда нужно иметь переиспользуемый кусок шаблона в компоненте, но не нужно делать из него полноценный компонент.

Svelte считается в комьюнити самой быстрой библиотекой, но она даже близко не смогла конкурировать с представленными решениями.

Зря на Svelte наговариваете:


Svelte benchmark

image

И поддержка Sourcemap имеется

Через адаптер разве что. Но соглашусь пример не очень контекстный вышел, хотел сказать, что ничто не вечно и подходы работавшие много лет(приносящие деньги, позволившие стать популярными за 3 года и прочее по тексту) тоже переосмысливаются и заменяются. Svelte3 смог радикально поменять свою парадигму за счет немногочисленности его использования до v3. Изначально предполагалось написать тулинг для конвертации компонентов, но никто не просил и забылось. Если доживем до предпосылок необходимости v4, то такой фокус провернуть уже не получится.

— Мажорные версии Svelte несовместимы между собой, при этом заявляется, что фреймворк готов для использования в продакшене.

Эм, на то они и мажорные. По вашему, как завезли хуки в React или composition api в Vue3 — сразу вон с продакшена эти нестабильные фреймворки/библиотеки?

Следующий митап должен был быть в Питере в апреле-мае, но пандемия внесла свои коррективы в наши планы.

Зарубежные коллеги завтра (26.04.2020) организуют очень обширный онлайн-митап — https://sveltesociety.dev/. Спикеры со всего мира, включая создателя фреймворка.

В вашем сравнении, я бы сказал, что это скорее колесо от 18-wheeler. Минимальный кирпичик, легко кастомизируемый под совершенно разные задачи. Реализаций сторов миллион, и Svelte совсем не обязывает использовать коробочный вариант, можно и MobX использовать. Для коробочного варианта фреймворк предлагает "сахар" в своих компонентах в виде автоподписок, но этот же "сахар" будет работать со всем observable-подобным(т.е. любой объект с методом subscribe), например популярный RxJS.

svelte/store никак не связан с механизмом реактивности Svelte. Это минималистическая реализация сторов аля Observable, работает в рантайме, т.е. спокойно можно использовать отдельно от Svelte, в своих проектах.

Ещё вы не знали, что Svelte умеет компилировать свои компоненты в web-компоненты(custom elements), которые нативно используют Shadow DOM для организации слотов и инкапсуляции. Повторю, это не фреймворк — это нативная фича web-компонентов.
Соответственно, никакого Shadow DOM при обычной компиляции нет и в помине.
Расскажите, как вы сравниваете Shadow DOM vs Virtual DOM, если утверждаете, что от одного можно прийти к другому?

Information

Rating
Does not participate
Location
Петрозаводск, Карелия, Россия
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Embedded Software Engineer
From 80,000 ₽
JavaScript
Svelte.js
Node.js
Docker
Linux