выучить react.js и не сойти с ума ))

материал свои стили пихает везде

Не, у него css-модули, стили с друрими не интерферируют.

выучить react.js и не сойти с ума ))

Not an option

выучить react.js и не сойти с ума ))

redux.js

Есть нюансов несколько только, но это решится переходом на прокси в 3 версии

Ну... Сейчас вообще такой тренд есть - процедурно-функциональный стиль с использованием ООП только для структуризации.

Он всегда такой был, программистов именно так и учат программировать. Геттеры/сеттеры/ООП и прочие штуки — это высший пилотаж уже, когда процедурно-функциональщины наешься.

Отсутствие сахара порождает тонны бойлерплейт кода, который вы потом будете выносить в отдельные функции и класть в utils.js А теперь подумайте, что очевиднее - налаженный сахар или ваши utils'ы

За это я предпочитаю Vue React'у

За это я предпочитаю Vue React'у

?

Он всегда такой был, программистов именно так и учат программировать. Геттеры/сеттеры/ООП и прочие штуки — это высший пилотаж уже, когда процедурно-функциональщины наешься.

ммм. Не) базовый вариант это процедурный стиль. Сейчас ООП заменяется на функциональщину в плане того что в тренде. Связано с тем, что большая часть столпов ООП стала антипаттерном считаться. Наследование еще 90-х очень рекомендовали не использовать и заменять композицией(чисто функциональный подход кстати). Полиморфизм часто плохая идея и кроме того не является ООП-специфичным. Инкапсуляция в ее чистом виде зачастую приводит к неподдерживаемой архитектуре.

За это я предпочитаю Vue React'у

но react.js прочищает мозги хорошо ))) час ебли с react.js равносилен двум дням трахания с vue.js )))

но react.js прочищает мозги хорошо ))) час ебли с react.js равносилен двум дням трахания с vue.js )))

Эм? Вы точно не перепутали?)

но react.js прочищает мозги хорошо ))) час ебли с react.js равносилен двум дням трахания с vue.js )))

реакт сам по себе убийственно простой же

Не понимаю, чем this.lol хуже this.getLol(), если вы знаете, что lol геттер

реакт сам по себе убийственно простой же

Видимо, вы не писали на Vue, раз так говорите)

Не понимаю, чем this.lol хуже this.getLol(), если вы знаете, что lol геттер

Нужно знать. Нужно следить за этим

Не понимаю, чем this.lol хуже this.getLol(), если вы знаете, что lol геттер

вот финалом. ЕСЛИ ВЫ ЗНАЕТЕ. а если не знаете? метод - implicit действие. геттер - неявное. хороший код избегает неявных действий.

Для реактера в Vue могут быть сложными только шаблоны вместо jsx первое время, но Vue тоже в него умеет

вот финалом. ЕСЛИ ВЫ ЗНАЕТЕ. а если не знаете? метод - implicit действие. геттер - неявное. хороший код избегает неявных действий.

Ля, вы пишете код Неужели, вы не знаете, что написали? А если не вы, то это какая-нибудь либа с докой, в которой это написано Лол

Ля, вы пишете код Неужели, вы не знаете, что написали? А если не вы, то это какая-нибудь либа с докой, в которой это написано Лол

Код пишу я и еще 10 человек, а потом я уйду, придет кто-то другой и ему разбираться.

Код пишу я и еще 10 человек, а потом я уйду, придет кто-то другой и ему разбираться.

Что ваша команда пишет?

В сторонней и хорошо документированной либе использование методов или геттеров/сеттеров - абсолютно без разницы

Я только про собственный проект говорю.

Что ваша команда пишет?

код. в основном. не понимаю вопроса

ммм. Не) базовый вариант это процедурный стиль. Сейчас ООП заменяется на функциональщину в плане того что в тренде. Связано с тем, что большая часть столпов ООП стала антипаттерном считаться. Наследование еще 90-х очень рекомендовали не использовать и заменять композицией(чисто функциональный подход кстати). Полиморфизм часто плохая идея и кроме того не является ООП-специфичным. Инкапсуляция в ее чистом виде зачастую приводит к неподдерживаемой архитектуре.

Ну, сейчас отдельно программисты и отдельно кодировщики. Раньше все-же кодировщики ничего на гитхабе не публиковали в таком объеме.

Ну, сейчас отдельно программисты и отдельно кодировщики. Раньше все-же кодировщики ничего на гитхабе не публиковали в таком объеме.

кто такие кодировщики я не знаю, но вообще всю жизнь функциональщина считалась чем то сложным и "высшим пилотажем", а не ООП.

кто такие кодировщики я не знаю, но вообще всю жизнь функциональщина считалась чем то сложным и "высшим пилотажем", а не ООП.

Функциональщина — это что такое в вашем понимании? И с чего вы это взяли?

Функциональщина — это что такое в вашем понимании? И с чего вы это взяли?

Функциональное программирование. Точнее паттерны характерные для функционального программирования. Чистые функции, мемоизация, иммутабельность, монады, декларативный стиль кода и прочая прочая

Функциональное программирование. Точнее паттерны характерные для функционального программирования. Чистые функции, мемоизация, иммутабельность, монады, декларативный стиль кода и прочая прочая

Это все, в общем-то обычные вещи, не то, чтобы специфичные для функциональщины. Просто базисная теория другая.

всем привет

вот финалом. ЕСЛИ ВЫ ЗНАЕТЕ. а если не знаете? метод - implicit действие. геттер - неявное. хороший код избегает неявных действий.

Хороший код - это когда вообще программисту без разницы является ли this.lol обычным свойством или у него есть геттер/сеттер.

код. в основном. не понимаю вопроса

ну проекты какие-то или низкоуровневый код

Толь, отформатируй пожалуйста прежде чем сюда постить такие портянки

а еще лучше на gist.github.com

Хорошо, что ещё есть админы, которые трут жесткач

Это все, в общем-то обычные вещи, не то, чтобы специфичные для функциональщины. Просто базисная теория другая.

Эти концепции пришли из функционального программирования. Это не значит что их можно использовать только в чисто функциональных языках конечно же, точно так же как ООП паттерны можно использовать в не-ооп языках.

ну проекты какие-то или низкоуровневый код

и то и то, но в основном проекты

Ну в проектах юзать геттеры да, нежелательно А что-то низкоуровневое - вай нот? Это упрощает жизнь все-таки

Нужно знать. Нужно следить за этим

А насчет этого утверждения - все нужно знать, за всем нужно следить. Джун обосрется и там, и там, если уж на то пошло

А насчет этого утверждения - все нужно знать, за всем нужно следить. Джун обосрется и там, и там, если уж на то пошло

Можно договориться писать очевидный код и знать станет проще

Можно договориться писать очевидный код и знать станет проще

“очевидный код” это очень субьективно

Ну в проектах юзать геттеры да, нежелательно А что-то низкоуровневое - вай нот? Это упрощает жизнь все-таки

Я ж и не говорю что геттеры это вселенское зло и они ответствены за геноцид народов) Скорее о том, что это "опасный" инструмент который нужно очень аккуратно использовать и только в случаях где это точно ок.

Можно договориться писать очевидный код и знать станет проще

Нужно просто знать, когда можно, а когда нет А не говорить ля говно неочевидное

договориться можно о каких-то паттернах и приемах которые вся команда будет считать понятными

Конечно, можно понапихать их везде и словить fatigue

Но так можно про любую фичу сказать

Нужно просто знать, когда можно, а когда нет А не говорить ля говно неочевидное

лучше сказать как раз. мне кажется про такие фичи лучше говорить "это плохая фича, никогда ее не юзайте". те кто разбирается - будут и так использовать там где они точно знают что можно. а всем остальным лучше не использовать никогда.

Всем остальным, в таком случае, лучше вообще не программировать, ибо так и будут от всего отказываться, потому что им дядя сказал, что это плохо

Так и будут писать на goto потом и утверждать, что цикл - очень ресурсоемкая операция (а ведь такое было один раз)

Так и будут писать на goto потом и утверждать, что цикл - очень ресурсоемкая операция (а ведь такое было один раз)

Ну прям за уши притянул)

Всем остальным, в таком случае, лучше вообще не программировать, ибо так и будут от всего отказываться, потому что им дядя сказал, что это плохо

ну я не согласен. есть куча методик и паттернов помогающих делать код очевидным и понятным для посторонних. геттеры в этом плане - довольно жесткий антипаттерн в подавляющем большинстве случаев.

Ну прям за уши притянул)

Нет, не за уши) Я знаю такого человека

парни, может в @holywars_ru?

один о теплом, другой о мягком

парни, может в @holywars_ru?

Отличная идея, там хоть можно собеседника пидором назвать

ну я не согласен. есть куча методик и паттернов помогающих делать код очевидным и понятным для посторонних. геттеры в этом плане - довольно жесткий антипаттерн в подавляющем большинстве случаев.

"Подавляющее большинство", я вас понял

Когда аргументы закончатся

лучше сказать как раз. мне кажется про такие фичи лучше говорить "это плохая фича, никогда ее не юзайте". те кто разбирается - будут и так использовать там где они точно знают что можно. а всем остальным лучше не использовать никогда.

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

парни, может в @holywars_ru?

Найс послал

Найс послал

ну адовый разговор ни о чем ?

лучше сказать как раз. мне кажется про такие фичи лучше говорить "это плохая фича, никогда ее не юзайте". те кто разбирается - будут и так использовать там где они точно знают что можно. а всем остальным лучше не использовать никогда.

Не согласен. Те же геттеры - неплохая фича. Почему? Потому что их можно использовать правильно без особых на то усилий. А если человек не может использовать геттеры правильно, значит у этого человека проблемы и даже если ему запретить юзать геттеры, то он обязательно накосячит с чем-нибудь другим. С промисами например.

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

да не. просто вижу очень много плохого кода on a dayli basis

ERROR: S client not available

ну адовый разговор ни о чем ?

Тут слой иронии повыше

да не. просто вижу очень много плохого кода on a dayli basis

Хочешь я тебе секрет открою? Это каждый программист делает. А вот так реагируют далеко не все.

ну адовый разговор ни о чем ?

@it_holywars чятик

@it_holywars чятик

ок, запишу

Хочешь я тебе секрет открою? Это каждый программист делает. А вот так реагируют далеко не все.

как, так?) хотят чтобы больше людей использовало подходы позволяющее писать более хороший и понятный код?)

ладно надо сворачиваться

кто такие кодировщики я не знаю, но вообще всю жизнь функциональщина считалась чем то сложным и "высшим пилотажем", а не ООП.

ООП ортогонально функциональщине

Это все, в общем-то обычные вещи, не то, чтобы специфичные для функциональщины. Просто базисная теория другая.

ну вот отличие "функционального ООП" от "императивного ООП" как раз в том, что функциональное построено на стройной математической теории, тогда как за "императивным ООП" никакой теории вообще нет

вместо привычных ООП-паттернов в функциональном мире алгебраические структуры - всё то же самое, только по-человечески формализовано

@KolesnichenkoDS в @it_holywars

Тут начинаю тереть ваш офтопик

ура

Юра, в холиварс плиз

Ребят, поделитесь воображением, помогите придумать решение бизнес-задачи. Проблема: с бэкенда приходит список из n элементов. На фронте есть мультиселект, который эти элементы отображает. Если в списке over 2000 записей, браузер, естественно, падает. Как решал: 1) Хотел сделать компонент с виртуальным скроллом, который подгружает контент в дом только по скроллу. Не смог соединить его с нашим мультиселектом. С этим способом зафакапился. 2) Хотфикс в лоб - показывать просто инпут, вместо мультиселекта, если записей слишком много и пусть юзер сам вводит значения. Так себе решение, топорно как-то. Может есть какой-то лайтовый способ как-то красиво этот список юзеру показывать?

автокомлит классический

с запросом к эластику

Ребят, поделитесь воображением, помогите придумать решение бизнес-задачи. Проблема: с бэкенда приходит список из n элементов. На фронте есть мультиселект, который эти элементы отображает. Если в списке over 2000 записей, браузер, естественно, падает. Как решал: 1) Хотел сделать компонент с виртуальным скроллом, который подгружает контент в дом только по скроллу. Не смог соединить его с нашим мультиселектом. С этим способом зафакапился. 2) Хотфикс в лоб - показывать просто инпут, вместо мультиселекта, если записей слишком много и пусть юзер сам вводит значения. Так себе решение, топорно как-то. Может есть какой-то лайтовый способ как-то красиво этот список юзеру показывать?

React-select

не нужно over 2k записей https://t.me/react_js/228084 вот все правильно написали, хоть и не обязательно к эластику, к чему угодно вообще

Ну 2к не проблема с фильтром

Кмк

Чужой кастомный компонент или либу не получится прикрутить - там монструозный мультиселект такой, я пытался уже, у меня просто коэффициент интеллекта не хватило столько сущностей в голове удержать

не нужно over 2k записей https://t.me/react_js/228084 вот все правильно написали, хоть и не обязательно к эластику, к чему угодно вообще

Отвечать на сообщения простым reply уже не модно???

а что там с фильтром? есть какой-то конкретный способ?

сорри, я просто в телеграме особо не сижу, не знал

Отвечать на сообщения простым reply уже не модно???

какая разница, все понимают на что ответ

не нужно over 2k записей https://t.me/react_js/228084 вот все правильно написали, хоть и не обязательно к эластику, к чему угодно вообще

а что значит эластик?

а что значит эластик?

На бекенде фильтруй

На бекенде фильтруй

на бэке хотел сам, мне отказали просто

Чужой кастомный компонент или либу не получится прикрутить - там монструозный мультиселект такой, я пытался уже, у меня просто коэффициент интеллекта не хватило столько сущностей в голове удержать

Но я бы начал с рефакторинга этой жопы

эластик - elasticsearch