Как выбрать Open Source лицензию для RAD фреймворка на GitHub

Вот тут в файле LICENSE эта строка не заполнена. Простите меня за такую дотошность )))

Как выбрать Open Source лицензию для RAD фреймворка на GitHub

А разве в тексте лицензии вот это место заполнять не надо?

Copyright [yyyy] [name of copyright owner]

Настоящее реактивное программирование в Svelte 3.0

Что он и делает…

Настоящее реактивное программирование в Svelte 3.0

color — не есть часть стейта! Меняется только percent! При его изменении не всегда нужно обновлять DOM!

Настоящее реактивное программирование в Svelte 3.0

Не важно, что изменится. Если shouldComponentUpdate вернет false (а он вызывается перед render), то render не произойдет.

Настоящее реактивное программирование в Svelte 3.0

Реакт же вызовет render()

В том то и дело, что не вызовет — именно для этого используются shouldComponentUpdate или PureComponent.

Настоящее реактивное программирование в Svelte 3.0

Какая разница иметь несколько компонентов в одном файле или в одном каталоге? Это же просто про индивидуальность работы в команде. Если продукт не позволяет иметь более одного компонента в файле, что мешает экспортировать компоненты из этих файлов через один общий файл (тот же index)?

Настоящее реактивное программирование в Svelte 3.0

Нет, Вы суть не уловили… гораздо лаконичнее и я мог написать…
Суть в том, сколько раз компонент «перерисуется» при изменении percent от 0 до 100?
В моем случае обновление DOM («перерисовка» компонента) произойдет всего 4 раза.

Настоящее реактивное программирование в Svelte 3.0

Посмотрел на lifecycle Svelte — да, есть знакомые методы: onMount, onDestroy, before/afterUpdate. C ходу не увидел метод, аналогичный render в React, но судя по философии Svelte — «A component is a reusable self-contained block of code that encapsulates HTML, CSS and JavaScript that belong together, written into a .svelte file» — он и не нужен.
Т.е. нельзя в одном файле содержать несколько компонентов или что-то не уловил?

А пример кода такой (чисто для передачи сути):

import * as React from 'react'

export type GraphCounterProps = { percent: number}
export class GraphCounter extends React.Component<GraphCounterProps, {}> {	
	private _color: string[]
	constructor(props: GraphCounterProps) {
		super(props)
		this._color = ['green', 'yellow', 'red', 'red']
	}

	shouldComponentUpdate(nextProps: GraphCounterProps) {
		return (Math.round(this.props.percent / 30) === Math.round(nextProps.percent / 30)) ? false : true
	}

	render() {
		return (
			<span 
				style={{
					color: this._color[Math.round(this.props.percent / 30)], 
					width: 100, 
					height: 20
				}}
			/>
		)
	}
}

Настоящее реактивное программирование в Svelte 3.0

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

Видеонаблюдение на orange pi zero — дешево и совсем не сердито

«правильная установка» — имелась в виду такая установка, когда не ясно, wi-fi это камера или нет… мне все-таки кажется, что на текущий момент подавляющее большинство камер — не wi-fi… и поэтому трата 50-100 евро себя не оправдывает… проще капюшон надеть )))…

Видеонаблюдение на orange pi zero — дешево и совсем не сердито

цена вопроса глушилки?.. стОит ли она того?.. да и довольно непросто определить, wi-fi это камера или нет при «правильной» ее установке…

Настоящее реактивное программирование в Svelte 3.0

А this.setState вы обязаны вызывать каждый раз, когда собираетесь изменить данные.

Тоже самое делает Svelte у себя внутри, только это уже никак не контролируется разработчиком. В React можно четко описывать, когда нужно делать обновление состояния (например, не всегда изменение переменной должно приводить к изменению DOM).
Хотя соглашусь, для простых случаев подход Svelte довольно удобен.

А если команда работает на JQuery, а не на React?

Эммм… и в чем проблема?...JQuery — просто библиотека… подключить ее к React не проблема…

Настоящее реактивное программирование в Svelte 3.0

> Если вы не сообщите React, что данные изменились (вызвав this.setState или эквивалентный хук), виртуальный DOM не изменится, и от React не последует никакой реакции (та-дам! ).

Тоже самое будет, если не указать $: в Svelte.

> Представьте, что вы только начали изучать веб-разработку. Какой код был бы для вас менее понятен? Тот, что слева, или тот, который справа?

А если не только начали и работаете в команде? Какой код будет более понятен без чтения доп мануалов?

Ну и отсутствие typescript, конечно, огромный минус…

Учебный курс по React, часть 11: динамическое формирование разметки и метод массивов map

Причем тут разметка? Динамическое формирование элементов — это да. А название статьи звучит как будто обсуждается динамическое позиционирование элементов.

Использование Babel и Webpack для настройки React-проекта с нуля

В данном случае правило будет применяться ко всем файлам с расширениями .m и .js

У webpack какой-то свой синтаксис для RegExp? Разве в данном случае правило будет применяться не ко всем файлам с расширением .mjs и .js?

Повторная децентрализация веба. На этот раз навсегда

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

Повторная децентрализация веба. На этот раз навсегда

Когда-то многим было сложно понять куда и как вбивать URL. Всему свое время и новое когда-то станем обыденным и проще…

Решение отсутствия prevProps в getDerivedStateFromProps

Я пока не использовал getDerivedStateFromProps(), но в componentWillReceiveProps() использую только nextProps. Да, первого рендера не избежать в любом случае — для минимизации его я делаю так:

render() {
	if (!this.state.service) { return null }
	return (...)
}

Далее для избежания ненужных рендеров:

shouldComponentUpdate(nextProps: ServiceModalProps) {
	return (!nextProps.sid) ? false : true
}

Ни и промисы с обновлением состояния тоже только когда надо:

componentWillReceiveProps(nextProps: ServiceModalProps) {
	if (nextProps.sid) {
		this.getService()
	}
}

Возможно что-то не учел (например, изменение this.props.sid, но проверку на это можно сделать также в shouldComponentUpdate()) или не допонял — не пинайте сильно…

Решение отсутствия prevProps в getDerivedStateFromProps

но тогда рендер будет происходить 2 раза

shouldComponentUpdate()?..