Комментарии 17
Лучше всего воспользоваться специальным адаптером(он же подойдет и для аналогичного встраивания в 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"));
Все хорошо, но почему "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
Статья полезная, спасибо. Не знал про поддержку 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;
};
}
Тайпинги также можно загенировать в авто-режиме на базе той же тулы. Конечно пока, что она не поддерживает 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 =)
Переиспользуемый компонент Svelte: чтобы никому не было больно