Обновить
5
Кирилл Халитов@Voronar

Интересное про фронтэнд https://t.me/frontendart

7
Подписчики
Отправить сообщение
Это то есть, но мне интересно послушать тех кто его использовал в реальных проектах.
Что подразумевается под простотой развёртывания? Установил 3 пакета и ты уже делаешь конечный spa-продукт?
Кто может сказать в двух словах в чём особенность этого фреймворка по сравнению с проверенными временем библиотеками и фреймворками (react, angular, etc.)?
В ES6 ещё можно так делать:
function Component(str, ...vals) {
  const props = vals[0];
  const children = vals[1];
  //...
}

function render() {
  const props = {};
  
  return (
    Component`${props}${
      Component`${props}${'nested'}`
    }`
  );
}
Как в советское время без всех этих сервисов рождались выдающиеся учёные, инженеры и другие кадры?
Нет, но вы можете использовать idom при построении приложений с помощью подхода MVC.
На русском не встречал. Насколько я знаю из беглого прочтения одной статьи, разница в том, что в отличии от vdom, который сначала обновляет виртуальное DOM-дерево(после этого ища разницу между виртуальным и реальным DOM-деревом и внося изменения в последнее), idom вносит изменения сразу непосредственно в реальное DOM-дерево по средствам «патчинга».
С какого это перепуга Incremental DOM стал альтернативной реализацией Virtual DOM?
Читаем первоисточник:
Incremental DOM is a library for building up DOM trees and updating them in-place when data changes. It differs from the established virtual DOM approach in that no intermediate tree is created (the existing tree is mutated in-place).
В таком случае вам подойдёт вот эта книга Getting MEAN with Mongo, Express, Angular, and Node.
Тут всё начинается с серверного рендеринга на ноде, продолжается с добавлением ангуляра для динамичности, и заканчивается SPA.
Прочитал пол книги, в целом неплохо, главное, что без воды. Теория всегда подкрепляется практическими примерами, которые можно скачать на гитхабе.
Конечно тут нету ES6, ангуляр компонентов и всех остальных передовых вещей. Здесь делается упор на процесс построения приложения согласно подходу MEAN.
Как давно Веб Компоненты стали CSS-фрейворком/библиотекой?
По поводу CSS. На самом первом этапе я вообще искал возможность создать новое CSS-свойство, чтобы интегрироваться в систему классов и не придумывать группы. Но такой возможности не нашёл и тогда решил делать дополнение в виде element.xstyle.
С другой стороны появляется возможность делать вложенные подкатегории стилей типа element.xstyle.styleCategory:
element.xstyle.declare(
{
  prop1: value,
  styleCategory:
  {
    prop1: value
  }
});
Да, я не понимал сути создания фреймворков на JavaScript и вы мне её объяснили. Спасибо.
Но я и не фреймворк собираюсь делать, а небольшую библиотеку(как видно из первого обзаца статьи) сугубо для личных целей. Но если кого-то заинтересует концепция этой библиотеки, то я рад был бы выслушать их предложения по совершенствованию этой концепции.
Тут вы попали в точку!
Сначала хотелось сделать что-то своё, но после анализа уже имеющихся библиотек захотелось предложить именно дополнение к ним. Но дополнение независимое от этих библиотек, так как многие пишут на чистых Веб Компонентах. То есть просто подключил модуль(import * as lib from «lib»;) и реализуешь непосредственно свои собственные элементы.
По поводу разных размеров типов на разных хостах.
Тут ответственность лежит на разработчике C++, объявляющем в своём коде структуры или массивы. При объявлении он должен исходить из того, чтобы его 32-битный int должен быть именно такого размера, а не 16 или 8 бит. А если не уверен, то пусть делает #ifdef.
JS-код же может гарантировать, что ctype.int32 будет именно 32-битный.
Сейчас я начинаю понимать, что Реакт мне тут ничем помочь не может.
Насколько я понимаю, Реакт — это просто композиция встроенных элементов и Реакт-компонентов, ещё конечно есть конвертация Реакт-компонентов в custom elements.

Я же говорю именно о новых встроенных элементах(custom elements), со своей логикой и поведением. Таких элементах, которые я могу включать через HTML-файл, стилизация и поведение которых делается близким по подходу как для встроенных элементов.
В двух предложениях тут не ответить.

Просто напишите пару строк кода.

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

А так зачем мне два отельных элемента, если я только один описываю?

P.S. Ушёл спать. Отвечать буду завтра.
Сейчас уже не могу в полном осмыслении проанализировать код потому что собираюсь спать.
Первое, что бросилось в глаза — это создание двух элементов «x-element» и «x-element-column-5», как показали на примере Реакта(«Histogram» и «Histogram5») Зачем мне два элемента для одной сущности(элемент гистограммы ведь один)?

И какую вторую половину не решает моя концепция?

P.S. Ушёл спать. Отвечать буду завтра.
Как в таком подходе динамически, во время выполнения менять значения атрибутов(columnWidth например). Как вообще получить доступ к элементу из вне?
И допустим мне захотелось убрать из первой гистограммы сгруппированные атрибуты(по аналогии с element.classList.remove(«StyledHistogram5»)) и вернуть их к изначальным(по умолчанию) значениям?
Да, и почему Histogram5 и StyledHistogram5 описываются отдельно? Слишком много лишнего кода получается для группировки свойств.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность