Как стать автором
Обновить

Комментарии 17

Где посмотреть как включить такой вот Clock в React компонент, например как children?

Лучше всего воспользоваться специальным адаптером(он же подойдет и для аналогичного встраивания в 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"));

Аналогично в 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>

Все хорошо, но почему "peerDependencies": { "svelte": "*" }? Неужели оно и со Svelte 2 совместимо?

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

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

Все равно непонятно, почему бы не написать "peerDependencies": { "svelte": "^3.0.0" } и тем самым избавить от проблем как пользователей предыдущей версии, так и гипотетической 4.0

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

В целом версии были совместимы. Т.е. используя свежий рантайм, компоненты со старым должны работать корректно, если они и до этого работали. В основном новые версии привносят только фиксы и новые фичи, старое поведение не меняется.
По крайней мере у меня такой опыт был со svelte

А это уже, как говорится, не проблема NPM. Если используется semver, а выглядит, что вроде бы так — то при ломающих совместимость изменениях, должна меняться мажорная версия. А если она не ломающая совместимость, тогда `"^3.0.0"` при последней `3.1` NPM установит её и ничего не должно сломаться.

Статья полезная, спасибо. Не знал про поддержку svelte атрибута в package.json. Обычно ссылаюсь по пути компонента напрямую без реимпорта.
Хочу еще добавить, что документацию полезно писать напрямую внутри компонента, чтобы иметь intellisence в vscode при разработке. А в ридми и т.д. уже вытаскивать автоматически с помощью этой штуки https://www.npmjs.com/package/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;
    };
  }
Для уже скомпилированного, jsdoc конечно же уже не подойдет. Я говорил про работу напрямую со svelte компонентами. В основном, работать приходится именно так.
Тайпинги также можно загенировать в авто-режиме на базе той же тулы. Конечно пока, что она не поддерживает TS в компонентах, но скоро планируется, так же как и формирование документации и тайпингов

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

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

Звучит как вызов! :D
Проверил, парсит параметры слотов:


Пример компонента и результата
<script>
    export let items = [];
</script>

<div>
    {#each items as item}
        <slot prop={item}></slot>
    {:else}
        <slot name="empty"></slot>
    {/each}
</div>

"slots": [
        {
            "name": "default",
            "description": null,
            "visibility": "public",
            "parameters": [
                {
                    "name": "prop",
                    "visibility": "public"
                }
            ]
        },
        {
            "name": "empty",
            "description": null,
            "visibility": "public",
            "parameters": []
        }
    ],

они уже значительно развитее, чем я смотрел последний раз.
Взяли приоритет на поддержку TS, чтобы пробиться в офф сборку svelte тулов для разработки. А пока что только тут используется

PS. Очень буду рад любым вопросам/багам и фидбекам на гитхабе по поводу библиотеки, моя поделка.

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

У меня уже очень давно весит в стеше генератор маркдауна, надо бы его освежить и преобразовать в нечто вроде sveltedoc-gen, который будет генерировать и markdown и typings

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации