Abnormal programming
JavaScript
ReactJS
Comments 17
0

О как! Недавно столкнулся с подобной проблемой и пришлось писать свой велосипед. Но оказывается уже есть более лаконичное решение. Спасибо!

+1
Насчет первого случая
 <Todo key={todo.id} todo={todo} onClick={onTodoClick} />

Так не произойдет никакого перерендеринга.
0
А они не PureComponent, а обычные StatelessFunctional. А значит перерисуются вместе с родителем, который перерисуется при любом изменении в любом из Todo.

Вообще вещать побольше connectов исключительно для контроля над распространением изменений — интересная практика.

Connect — начало любого изменения, потому что дергается непосредственно стором как бы глубоко он не сидел
Connect — конец любого изменения, потому что SCU не пропустит никакие нежданные изменения прилетевшие сверху.

Подробнее можно вот тут почитать -> medium.com/@alexandereardon/performance-optimisations-for-react-applications-round-2-2042e5c9af97
+1
до фрактала набрел на такое(это форк с небольшими изменениями): github.com/plandem/react-redux-controller и, честно говоря, с тех пор такой подход мне нравится все еще больше, чем фрактал или то, что в статье. Там хотя бы есть какое-то упрощение кода.
0
Freactal прекрасен, как и многие другие решения. К сожалению требовалось «починить» именно что redux. И именно способом, максимально близким к идеалогии redux.
По другому идею не продать.
0
Ну вы, по сути, на Redux и делаете фрактальный стейт (можно было об этом, собственно, явно в статье указать). Концептуально очень похоже на Fractal или cycle-onionify.
0

Отличное решение, должно сильно упростить составные состояния.


По поводу статьи: не оставляйте необъявленных переменных в примерах, излазился в поисках onTodoClick.

0
Может я конечно чего-то не понял, буду признателен если поправите. Но возникло стойкое ощущение, что вы себя просто мучаете зазря. Такие сложности на пустом месте.

Чисто для сравнения компонент TreeView на основе данных из плоского массива на SvelteJS:

TreeView.html
<ul>
	{{#each leafs as leaf}}
	<li id="leaf{{leaf.id}}">
		<h6>{{leaf.title}}</h6>
		{{#if leaf.childs}}
		<:Self leafs="{{childs(leaf.childs)}}" />
		{{/if}}
	</li>
	{{/each}}
</ul>

<script>
	import tree from './tree.js'
	
	export default {
		data: () => ({
			leafs: []
		}),
		helpers: {
			childs: childs => tree.apply(null, childs)
		}	
	};
</script>


Вот живой пример поиграться. Можно выставлять любые начальные id-шники дерева в json-объекте справа.

На полном серьезе не понимаю, почему столь простая задача должна решаться так сложно. Конструктивная критика приветствуется.
0
Tree был использован как пример «погружения» и «всплытия». Просто как удобный пример.
0
Понимаю, но по моему опыту статьи про React почему-то делятся на 2 вида: 1) как красно что мы выбрали React, вот какой классный “Hello World”; 2) решаем проблемы React.

Создаётся стойкое ощущение что вы себя мучаете только бы чтоб использовать React. Раз с React так много проблем, то может использовать другие решения?
+1
статьи про React почему-то делятся на 2 вида: 1) как красно что мы выбрали React, вот какой классный “Hello World”; 2) решаем проблемы React.

«Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.» Бьёрн, Страуструп
0
Видимо он это писал о C++. Не знаю как вы, а я на этом языке писал 4 года и по моему мнению это такое же оправдание, как высказывание Черчилля про демократию.
0

А чем хуже с точки зрения производительности:


const TodoList = ({todos}) => (
  <ol>
    {todos.map( item => <ConnectedTodo key={item.id} item={item}  />)}
  </ol>
);

чем предложенный вариант по ID?


const TodoList = ({todos}) => (
  <ol>
    {todos.map( id => <ConnectedTodo key={id} id={id}  />)}
  </ol>
);

Во варианте с item мы же так же можем не рендерить если нет изменений (при условии иммутабельности item).

0
Возможно прямо так сравнивать не совсем корректно, но второй вариант сам добавит «иммутабельность», в виде sCU из connect врапера redux.
Если же добавить memoize-state из моей другой статьи, но «контейнер» будет регировать только на изменение колличества todo или ID, полностью игнорируя данные внутри todo элементов, что уже может быть интересно в некоторых случаях.

Еще один плюс — данный подход позволяет «разорвать» связь стейта, его использования и редьюсера.
Сейчас редьюсер и селектор в неком смысле «симметричны», возможность модифицировать стейт под нужды клиента позволяет это ограничение(это — ограничение) разорвать.
0

Да, но зато так мы б могли обойтись только массивом todo и никаких индексов из ID не надо. Имхо, идея с ID здравая и элегантная, но это тот случай, когда с водой ребенка выплеснули. Лучше какой-то средний вариант взять, т.е. не спредать item в компонент, но и не закручивать гайки по максимуму с селектором по ID в connect. А чтоб работало совсем по красоте можно еще и обернуть в onlyUpdateForKeys из recompose, чтоб заигнорить лишнее.

Only those users with full accounts are able to leave comments., please.