да, форк react-scripts (не create-react-app), и этот подход официально поддерживается, я кидал ссылку на тред.
И это как только будут новые фичи в react-scripts — они так же будут и тут.
Ну по сути это и есть Symfony2 Service Container только не с полным её функционалом. А дальше что? Линивая инициализация, наследование сервисов, собственные pass compilers? Как раз не давно искал не большой IoCc, смотрел в сторону Pimple.
Вы сравнивали быстродействие вашего контейнера с другими сущесвующими? Symfony, если не ошибаюсь, дампит конфиг сервайсов в пхп код и не парсит его каждый раз.
2. Погонял туда-сюда числа продуктов и категорий — соотношение скорости между голым PHP и YaLinqo сохраняется, так что остаюсь убеждённым про тот же порядок сложности.
Очень круто, когда есть график, когда по X — размер данных, по Y — время :) Особенно если на графике показано несколько реализаций решения.
PHP и хайлоад в одном предложении — признак недальновидности.
Тоже спорно. Это уже как стереотип — ПХП плохой, подходит только для бюджетных не больших проектов.
С правильным подходом и хорошей архитектурой приложения — мощный инструмент, с помощью которого вполне можно и хайлоад приложения разрабатывать.
Просто слово «хайлоад» — резиновое. Нужно более конкретно говорить :)
P.S. На пхп писать «говнокод» в разы легче и порог вхождения низкий, в отличии от других языков, по этому так и бывает, что когда видишь уже готовый проект — начинается паника :)
Да, точно. Времени не было толком, что бы сделать все. Вот с сортировками правильными (хотя может и тут ошибки есть):
Разница с предыдущим вариантом использования нативного — не велика.
Мера О та же самая. Коэффициенты и константы, разумеется, отличаются.
Я почемуто уверен, что вложенность будет выше, соотвестно степень N будет возростать.
Для решения на нативном коде — потребуется больше времени, хотя есть такая мудрость — «Нету смысла подключать дополнительный пакет компонентов в 100500 строк, чтобы твой исходник уменьшился на 10 строк».
P.S. Я не осуждаю и не навязываю холивар. Я уважаю вашу работу. Я пытаюсь разобраться в этом — «использование дополнительных библиотек — это всегда жертвование ресурсов, и здесь важно знать, чем ты жертвуешь и в каком количестве»
По поводу «логической» сложности полностью согласен. А по поводу математической — нет. Ведь использование дополнительной функции, библиотеки, фреймворка — явно увеличивает сложность. Только что я не много потыкал под xhprof. Вот код с использованием либы, а вот нативный. И результаты:
Нативный:
С либой:
Видно, что с использованием либы — памяти раз в 5 больше и скорость выполнения — раз в 8 и количество вызываемых функциий — раз в 10. Если решать задачу с использованием SQL запроса — то еще быстрее.
Об этом я и спрашивал.
Я не спорю, что нативный код не всегда хорош (не учитывая хайлоад приложения), и подход который предлагаете Вы- явно удобнее и логически приятнее читать, особенно если бы не было лямбда функций в строках, но использование дополнительных библиотек — это всегда жертвование ресурсов, и здесь важно знать, чем ты жертвуешь и в каком количестве.
Сейчас вы начинаете строить в уме трижды вложенные циклы, вызовы функций для массивов
1. А при вызове функций библиотеки сколько вложенных циклов будет? К примеру, в вашем примере какая сложность алгоритма получается?
2. Ведь данные хранятся в БД, соотвественно нужные данные в нужном формате можно выбрать SQL запросом, что убдет явно быстрее чем их обработка на PHP.
3. Интересно было бы посмотреть сравнение быстродействия и используемой памяти:
— Использование SQL запроса;
— Обратботка сущесвующих массивов с помощью YaLinqo (хотя сюда нужно суммировать и выборку данных из БД, потому что вряд ли вы данные храниет в массивах);
— То же самое что и предыдущий вариант, только вместо библиотеки — реализация нанативном пхп под определенную задачу.
Решение как раз оказалось совсем не странное. Странно то, что мы автоматически перемещаем элемент из директивы в рутовый элемент. Но без этого никак:
— Как говорил выше, я считаю, что элементы которые взаимодействуют друг с другом должны быть расположены максимально близко друг к другу в исходном коде
— Если не перемещать элемент — то может поломаться его верстка (особенно если это сложные элементы — модальные окона, селект боксы, поповеры и так далее), так как он унаследует все CSS правила родителей.
К примеру popover:
<button popover-toggle>Add</button>
<popover>
Hello! I am popover
</popover>
На много удобнее, если он находится возле кнопки, с которой взаимодействует.
Вполне возможно Shadow DOM будет в помощь :)
Вообще я писал статью лишь по тому, что мен удивило как работает angularjs и для чего он использует комментарии.
Как по мне, то лучше, что бы элементы, которые взаимодейсвуют друг с другом (например кнопка «Show modal» и само окно) были максимально близко к друг другу, тем более если используется много темплейтов.
<button ng-click="show()">Show modal</button>
<modal>
Hello, I am modal window
</modal>
И так код более читаемый и понятный. Все заивсит от проекта. Можно использовать вместо директивы и сервис, а шаблон брать text/ng-template, но у нас много чего построено на именно директивах.
так там нету ничего про CRA кроме ссылки на RAW
И это как только будут новые фичи в react-scripts — они так же будут и тут.
Есть еще — custom-react-scripts — это кастомная версия react-scripts.
Здесь подробнее про custom-react-scirpts — Configure create-react-app without ejecting
Здесь можно почитать офф. инфу Document maintaining a fork of react-scripts as an alternative to ejecting #682
у товарища в хроме вообще не запустились примеры, ругалось на необъявленную переменную 'a'
так в Sf2 DI есть же теги для описания сервисов. Но в Syringe они реализованы по другому. Или мы о разных вещах говорим?)
Вы сравнивали быстродействие вашего контейнера с другими сущесвующими? Symfony, если не ошибаюсь, дампит конфиг сервайсов в пхп код и не парсит его каждый раз.
Очень круто, когда есть график, когда по X — размер данных, по Y — время :) Особенно если на графике показано несколько реализаций решения.
Тоже спорно. Это уже как стереотип — ПХП плохой, подходит только для бюджетных не больших проектов.
С правильным подходом и хорошей архитектурой приложения — мощный инструмент, с помощью которого вполне можно и хайлоад приложения разрабатывать.
Просто слово «хайлоад» — резиновое. Нужно более конкретно говорить :)
P.S. На пхп писать «говнокод» в разы легче и порог вхождения низкий, в отличии от других языков, по этому так и бывает, что когда видишь уже готовый проект — начинается паника :)
Вот с сортировками правильными (хотя может и тут ошибки есть):
Разница с предыдущим вариантом использования нативного — не велика.
Я почемуто уверен, что вложенность будет выше, соотвестно степень N будет возростать.
Для решения на нативном коде — потребуется больше времени, хотя есть такая мудрость — «Нету смысла подключать дополнительный пакет компонентов в 100500 строк, чтобы твой исходник уменьшился на 10 строк».
P.S. Я не осуждаю и не навязываю холивар. Я уважаю вашу работу. Я пытаюсь разобраться в этом — «использование дополнительных библиотек — это всегда жертвование ресурсов, и здесь важно знать, чем ты жертвуешь и в каком количестве»
Нативный:
С либой:
Видно, что с использованием либы — памяти раз в 5 больше и скорость выполнения — раз в 8 и количество вызываемых функциий — раз в 10. Если решать задачу с использованием SQL запроса — то еще быстрее.
Об этом я и спрашивал.
Я не спорю, что нативный код не всегда хорош (не учитывая хайлоад приложения), и подход который предлагаете Вы- явно удобнее и логически приятнее читать, особенно если бы не было лямбда функций в строках, но использование дополнительных библиотек — это всегда жертвование ресурсов, и здесь важно знать, чем ты жертвуешь и в каком количестве.
1. А при вызове функций библиотеки сколько вложенных циклов будет? К примеру, в вашем примере какая сложность алгоритма получается?
2. Ведь данные хранятся в БД, соотвественно нужные данные в нужном формате можно выбрать SQL запросом, что убдет явно быстрее чем их обработка на PHP.
3. Интересно было бы посмотреть сравнение быстродействия и используемой памяти:
— Использование SQL запроса;
— Обратботка сущесвующих массивов с помощью YaLinqo (хотя сюда нужно суммировать и выборку данных из БД, потому что вряд ли вы данные храниет в массивах);
— То же самое что и предыдущий вариант, только вместо библиотеки — реализация нанативном пхп под определенную задачу.
Да, но я посмотрел их исходники уже после того, как написал топик.
— Как говорил выше, я считаю, что элементы которые взаимодействуют друг с другом должны быть расположены максимально близко друг к другу в исходном коде
— Если не перемещать элемент — то может поломаться его верстка (особенно если это сложные элементы — модальные окона, селект боксы, поповеры и так далее), так как он унаследует все CSS правила родителей.
К примеру popover:
На много удобнее, если он находится возле кнопки, с которой взаимодействует.
Вполне возможно Shadow DOM будет в помощь :)
Вообще я писал статью лишь по тому, что мен удивило как работает angularjs и для чего он использует комментарии.
И так код более читаемый и понятный. Все заивсит от проекта. Можно использовать вместо директивы и сервис, а шаблон брать text/ng-template, но у нас много чего построено на именно директивах.