Pull to refresh
25
0
Alexey Schebelev @AlexxNB

Fullstack Javascript

Send message

Мне показалось, или по вашему получается Shadow DOM === Virtual DOM?

Да, безусловно можно ставить дополнительно БП(тем более GPRS-терминал все равно питания требует). Я просто, отметил, что при отсутствии внешнего питания у приборов существуют допуски на время активного порта, которые узнаются у производителя.

Я в своих краях сталкиваюсь в основном с батарейными. Примерно процентов 80. Но я думаю это от региона зависит и от того какие компании в свое время какие приборы лобировали.
С производителями батарейных можно пообщаться, и они расскажут сколько можно секунд в месяц держать порт открытым. Например для популярных некогда ВКТ-7(на фото присутствует) пределом был опрос текущих раз в 3 часа, лучше раза четыре в сутки. У их преемника ВКТ-9 делать опрос ежечасно проблемы не представляет

Мониторинг. Если общедомовой теплосчетчик на неделю отрубится (или случится еще какая беда, типа мусора в расходомере) и это вовремя не заметить, то можно влететь на большие деньги. С другой стороны раз в час опрашивать теплосчетчики с батарейным питанием излишне и можно посадить батарею раньше срока.

Из мелочей, как следствие декларативного подхода, в директивах типа "#if" нельзя использовать выражения, только ранее вычисленные значения.

Почему это? В блоке if можно использовать любое javascript выражение.

Может https://www.spotify.com тогда в противовес? =)

Вы можете встретить Svelte на главной странице https://mail.ru/ и https://money.yandex.ru. (определяется по соответствующим классам svelte-**** в коде).

Всего лишь вольный перевод фразы из учебника — Actions are essentially element-level lifecycle functions.

Подумалось, что при мало мальской сложности проекта, оптимально писать на ваниле человеку может стать не удобно, начнет вводить понятные для себя абстракции, совершать больше ошибок, где-то быть не оптимальным. В итоге окажется, что скомпилированная vanilla от Svelte, окажется лучше и по размеру и по быстродействию. Разработчик пишет со всеми плюшками, паттернами и удобствами компонентного фреймворка, на выходе получает оптимальнейший код на ваниле.

Но это именно, то что делает Svelte =) Скомпилированный код получается близок к тому, что бы вы написали на vanilla(в REPL можно посмотреть на вкладке JS Output). В рантайме остаётся кроме бизнес-логики, хелперы непосредственной манипуляции с DOM, подобные тому, что вы написали.

  1. Порталы

Могу предложить реализацию портала через экшены(ака действия, ака actions). Элегантнее получится.


<script>
  let show = false;

  function portalAction(node,parent){
        parent = parent || document.body;
        parent.appendChild(node);
  } 
</script>

<button on:click={()=>show = !show}>show</button>

{#if show}
    <div use:portalAction>content</div>
{/if}

Живой пример


Навешиваем экшен portalAction на элементы, которые должны уходить в "портал" при помощи директивы use:. Ещё можно указать в параметре экшена родительский элемент для перемещаемой ноды — use:portalAction={parentNode}. При монтировании элемента в DOM — экшн сработает и переместит его в указанный элемент. Демонтируется элемент штатным обработчиком Svelte, так что нет необходимости делать это в destroy функции экшена.


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

Поэтому и 10-key =)

Если у вас есть идеи, как это можно сделать элегантней, напишите об этом в комментариях.

Может и не элегантнее, но просто иной подход:


{#each new Array(10) as _,gridValue}
  <polygon
    points={`${getHexCorner((10-gridValue) * 10, direction)}, ${getHexCorner((10-gridValue) * 10, direction + 1)}, 0, 0`}
    strokeLinejoin="miter-clip"
    stroke-dasharray="4"
    stroke-width="0.5" />
{/each}

Большая такая компания, отец Реакта, продвигает в массы иммутабельность. Можно прислушаться, как мне кажется.

Так проблема то не в том, то плохо написано, а в том, что "мужики инструкции не читают".
Там всего три абзаца в этом разделе и один из абзацев конкретно про push и splice.

Facebook агитировали за immutable.js. Смысл в немутируемости объектов:


arr = arr.push(1);

Да и в целом тренд на иммутабельность начался задолго до Svelte.

Там вполне достаточно и понятно написано, почему нельзя использовать push, и что нужно делать https://ru.svelte.dev/docs#2_Prisvaivaniya_reaktivny. Документация действительно короткая, да и ту не читают.

Всё верно, "намазываются" только свойства и атрибуты. Т.е. в вашем варианте в компонент будет передано свойство с именем 'on:click', содержащее ссылку на функцию. Никаким образом она не будет относиться к соответствующему обработчику события.


Вот накидал пример, чтобы продемонстрировать это наглядно.

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

Синтаксис шаблонов дает место только для одного подписчика: <Button on:click={handleClick}/>

Можно два обработчика навесить, если надо:


 <Button on:click={handleClick1} on:click={handleClick2} />

Можно обработать ивент в текущем компоненте и передать на уровень выше:


 <Button on:click={handleClick1} on:click />

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