понял - в целом вы используете это или для новичков?

тебе надо делать eject

на самом деле нет - форкаешь реакт скриптс и настраиваешь как тебе надо

на самом деле нет - форкаешь реакт скриптс и настраиваешь как тебе надо

лучше реакт форкнуть

лучше реакт форкнуть

зачем реакт? форкаешь вебпак и впиливаешь туда свое приложение

Реакт большой. Пиши своё.

лучше реакт форкнуть

отличная шутка, но на самом деле нет. Про форк скриптов https://medium.com/@KarandikarMihir/porting-enterprise-react-app-to-create-react-app-bfb565a25460 Главный плюс можно апдейтить с апстрима CRA и иметь свои настройки при этом если сильно хочется

понял - в целом вы используете это или для новичков?

это только для самого-самого начала, тупо чтобы потыкать реакт либо для очень опытных разработчиков, которые хотят именно тот стек, что предлагает КРА

ясно

меня мучает идея а почему не сделали еще class-based конфиг чтобы можно было наследовать и править через методы?

конечно меня не мучает - но все же

он прост - но сложно когда надо изменить в связках - server/client + dev/prod/test

2*3 вариаций

и тогда код становится не ясным какой конфиг имеем

понял - в целом вы используете это или для новичков?

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

Да и я так считаю - но как показывает практика - включаешь какой-нить пакет и тут нужно include/exclude и уже игра с лоадерами. а разный/стек

а все что связано с react уже можно стандартизировать + babel/env

какой пакет например?

имею такую хрень import Button from "@nasdaq/ui/src/Button";Как сконфигурить packagejson nasdaq/ui так, чтобы убрать src?

на самом деле нет - форкаешь реакт скриптс и настраиваешь как тебе надо

Мне такой вариант вообще не подходит, бо куча проектов с разным стеком

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

Да причем тут фреймворк? У тебя есть задача, ты конфигурируешь сборщик под нее. При чем тут КРА? тоже самое, что говорить - "я считаю, что знать как браузер рендерит страницу - сомнительный скилл..."

имею такую хрень import Button from "@nasdaq/ui/src/Button";Как сконфигурить packagejson nasdaq/ui так, чтобы убрать src?

Не очень ясно, import {Button} from "@nasdaq/ui" логично должен работать

Да причем тут фреймворк? У тебя есть задача, ты конфигурируешь сборщик под нее. При чем тут КРА? тоже самое, что говорить - "я считаю, что знать как браузер рендерит страницу - сомнительный скилл..."

+

КРА, кстати, не делает вообще ничего особенного

Да причем тут фреймворк? У тебя есть задача, ты конфигурируешь сборщик под нее. При чем тут КРА? тоже самое, что говорить - "я считаю, что знать как браузер рендерит страницу - сомнительный скилл..."

потому что задача стоит “сделать проект” а не “настраивать сборщик"

тут можно бесконечн ооптимизировать

эм, почему? Нет, в моем пакете @nasdaq/ui есть файл Button.js с кпопкой в папке src

Такой же конфиг самому собрать несложно

меня больше беспокоит что есть less/sass/stylus/postcss

как говорится лучший интерфейс — его отсутствие

я хочу в другом пакете обратиться к нему, но без src

Вопрос ток в целесообразности

зоопарк

так же как и со сборщиками

потому что задача стоит “сделать проект” а не “настраивать сборщик"

А это разве не часть процесса? Может тогда индусов нанять - они запилят код

А это разве не часть процесса? Может тогда индусов нанять - они запилят код

если можно без настройки — можно без настройки

причем тут индусы?

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

как говорится лучший интерфейс — его отсутствие

во-во

я считаю что разраб вместо того чтобы ебаться со сборщиком лучше бы основы UX и дизайна подтянул

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

видимо, ты не знаешь)

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

вообще нужно знать как происходит reflow, repaint это точно понадобится при оптимизации

я еще помню те времена когда делал "ajax" через iframe для онлайн игр. так что все меняется и эта головная боль должна уйти

я еще помню те времена когда делал "ajax" через iframe для онлайн игр. так что все меняется и эта головная боль должна уйти

оптимизации никуда не денутся

я считаю что разраб вместо того чтобы ебаться со сборщиком лучше бы основы UX и дизайна подтянул

Макс, ну. Может в каких-то случаях и да. Я вот настроил вебпак на бандлы с асинхронной загрузкой и с телефона у меня приложенице открывается очень быстро. UX для человека, который зашел первый раз на сайт великолепен. Это норм, или зашквар?

даже если мы живем в огромной симуляции, можно приглядеться и увидеть оптимизации

Макс, ну. Может в каких-то случаях и да. Я вот настроил вебпак на бандлы с асинхронной загрузкой и с телефона у меня приложенице открывается очень быстро. UX для человека, который зашел первый раз на сайт великолепен. Это норм, или зашквар?

это отлично!

вообще нужно знать как происходит reflow, repaint это точно понадобится при оптимизации

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

вообще нужно знать как происходит reflow, repaint это точно понадобится при оптимизации

во-во. Да и изначально это позволяет не делать косяков, которые потом придется оптимизировать

Макс, ну. Может в каких-то случаях и да. Я вот настроил вебпак на бандлы с асинхронной загрузкой и с телефона у меня приложенице открывается очень быстро. UX для человека, который зашел первый раз на сайт великолепен. Это норм, или зашквар?

если у тебя это окупается — збс

вообще нужно знать как происходит reflow, repaint это точно понадобится при оптимизации

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

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

тут согласен полностью. Но все же необходимо знать как устроено, ибо можешь изначально построить приложение с учетом оптимизаций, а то потом боль

а не “сборщик надо знать потому что сборщик надо знать”

и какие свойства css как влияют

если у тебя это окупается — збс

Если UX лучше - значит окупается)

я считаю что разраб вместо того чтобы ебаться со сборщиком лучше бы основы UX и дизайна подтянул

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

но это должно быть опционально

всем хай, ай нид хелп. А как правильно сделать поле стейта вычисляемым ? ну т.е я в конструкторе компонента делаю this.state = { field:calculateNumber() }

а не “давайте всех заставим писать лапшу конфигов для вебпака"

если у тебя это окупается — збс

если не шаришь, то не поймешь как это повлияет на сайт/сервис/приложение и на окупаемость в будущем

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

Вооо. Согласен! Я один из первых продакшен проектов писал без понимания вебпака. Уже потом, когда разобрался во всем этом конфиге - понял, что многое работает не так

но это должно быть опционально

согласен. Но люди должны знать как всё устроено. По причинам которые я описал выше

серега, есть бизнес-требования и метрики

т.е я хочу вычислять значение стейта нал ету так сказать

я как то делал medium-like lightbox в далеком 2013 когда использовал модули и broserify это было космосом тк использовал классы. И чтобы анимацию сделать 60fps+ пришлось каждое свойсво дебажить и изменение и даже перейти на canvas и его показ(+fallback с img) - тк оказалось только он правно и красиво scale-ится

без них “быстрее” это пустой звук

Вот это была боль разработка

сейчас у меня он дефолтный = 0, и в компонентДиД маунт я делаю новый сетСтейт в нужным значением

ERROR: S client not available

если у меня саас, то мне плевать на +1-2 секунды загрузки

если это фишки.нет, то там другие требования

серега, есть бизнес-требования и метрики

Понятное дело. От этого никуда не убежать. Это нормально. Но пока человек учится, ему дают на это время и возможности, пусть лучше он изучит инструменты с которыми ему все равно придется работать, так или иначе, позже или раньше. Но намного дешевле для бизнеса, если разработчики изучит инструменты ещё на ранних стадиях, так как потом время разработчика будет стоить больше, как и время разработки проекта, то самое время, которое разработчик будет тратить на то, чтобы ебаться с инструментами которые он не изучил на ранних стадиях своего профессионального развития

согласен. Но люди должны знать как всё устроено. По причинам которые я описал выше

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

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

++

Понятное дело. От этого никуда не убежать. Это нормально. Но пока человек учится, ему дают на это время и возможности, пусть лучше он изучит инструменты с которыми ему все равно придется работать, так или иначе, позже или раньше. Но намного дешевле для бизнеса, если разработчики изучит инструменты ещё на ранних стадиях, так как потом время разработчика будет стоить больше, как и время разработки проекта, то самое время, которое разработчик будет тратить на то, чтобы ебаться с инструментами которые он не изучил на ранних стадиях своего профессионального развития

разработчик должен сначала реакт изучить

а потом учить как его собирать руками

если у меня саас, то мне плевать на +1-2 секунды загрузки

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

я еще раз говорю если ты пропустил — бизнес-требования и метрики

saas вообще не многое плевать и это супер

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

да это точно

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

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

а потом учить как его собирать руками

Это правда. Но зависит от позиции разраба. Если в конкретном проекте - катит стандартный конфиг - пускай. А если бизнес выставит другие требования через месяц - а разработчик не в теме, то выйдет не очень. Для помидора уж точно знание тулчейна обязательно

saas вообще не многое плевать и это супер

А какая разница?

я про erp/crm - загрузилось и работай

saas вообще не многое плевать и это супер

Если есть возможность сделать быстрее - это всегда херня

многие страницу неделями не перегружают и работают с системой

я еще раз говорю если ты пропустил — бизнес-требования и метрики

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

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

мой пойнт(и мой субъективный опыт) - в большинстве ситуаций вообще не надо тратить время на тулчейн, воткнул CRA и забыл

какая разница сколько оно первый раз грузилось

Есть такие сборки 1c что люди приходят на работу - запускают / ждут час пока она все данные заберет и сгенерирует и потом работают целый день и если перезапустят опять ждать час ) так что 2 сек тут не играют роли

мой пойнт(и мой субъективный опыт) - в большинстве ситуаций вообще не надо тратить время на тулчейн, воткнул CRA и забыл

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

Это еще про CRA дисскусия?!

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

+1. Ибо требования - очень тонкая тема. Они всегда разные, они всегда меняются

Есть такие сборки 1c что люди приходят на работу - запускают / ждут час пока она все данные заберет и сгенерирует и потом работают целый день и если перезапустят опять ждать час ) так что 2 сек тут не играют роли

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

Есть такие сборки 1c что люди приходят на работу - запускают / ждут час пока она все данные заберет и сгенерирует и потом работают целый день и если перезапустят опять ждать час ) так что 2 сек тут не играют роли

1с это вообще отдельная тема

А вы весёлые ребята.

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

удивился что react использует rollup

крутая штука но примения не вижу пока для себя

+1. Ибо требования - очень тонкая тема. Они всегда разные, они всегда меняются

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

роллап для либ же используют активно

удивился что react использует rollup

Потому что собирает лучше