Дефолтные аргументы создаются один раз при первом обращении к функции. Например, если бы по-умолчанию подставлялся список, то он был бы всегда один и тот же между вызовами:
def foo(bar=[]):
return bar
x = foo()
x.append(4)
y = foo()
В результате x и y ссылаются на один и тот же список.
Используете SSR? Что использовали для раутинга и как решали проблему Sode Splitting + SSR + Lazy Loading? Довелось в доке react-router видеть такую фразу:
Godspeed those who attempt the server-rendered, code-split apps.
Не могли бы Вы привести какой-нибудь пример, когда подобного рода утилитарные вещи убираются из состояния?
не хранить ошибки и временные штуки вроде isLoading полей в redux
Тут, мне кажется, больше проблема в том, что новички (и я в их числе) в поисках best practices встречаются с популярными, но не самыми лучшими архитектурными решениями.
Лично я в своем проекте использовал пример работы с OpenDota API и уже в процессе работы наткнулся на недостатки, озвученные Вами.
Спасибо за статью)
Интересно было бы еще узнать, как быть в случае с redux. Есть ли способы так же единообразно обрабатывать ошибки? Да, почти вся логика уходит в action-ы и reducer-ы, что позволяет обрабатывать их императивно, но при написании тех же запросов получения данных появляется довольно много бойлерплейта.
Была идея использовать отдельный action на обработку ошибок по http коду, а прочие исключение сводить к ним, но данное решение выглядит несколько криво, да и не особо удалось в силу того, что на беке ошибки контекстно зависели от запроса.
Прошу прощения, забыл про такую хитрую штуку (слышал о ней от разработчика из Microsoft, смотрел запись его выступления на dotnext), а именно — компилятор сам резолвит данное условное выражение в зависимости от таргета и подставляет соответствующий код. Так что здесь проверка абсолютно никакого оверхеда иметь не будет, но при этом будет полезной.
Интересно было бы сравнить различные варианты fallback-ов на больших данных.
Не могу не согласится, ибо у самого были случаи, когда находился пара пользователей с крайне специфичным железом :)
В данном вопросе больше ориентировался на предположение, что данный код будет исполняться на сервере.
Если я правильно трактую документацию Intel и википедию, то _mm_popcnt_u32 была представлена в наборе команд SSE 4.2 в 2007 году и ныне поддерживается большинством процессоров. Так что в современных условиях проверка, конечно, с точки зрения логики важна, но несколько избыточна.
Хотя при работе с интринсиками в первую очередь стоит ориентироваться на примерные характеристики целевого устройства (или набора устройств).
Да, Вы правы
Дефолтные аргументы создаются один раз при первом обращении к функции. Например, если бы по-умолчанию подставлялся список, то он был бы всегда один и тот же между вызовами:
В результате x и y ссылаются на один и тот же список.
Судя по Startup это сделано следующим образом:
Зарегистрировали конфиги БД, репозиторий, MediatR
Добавили в DI валидаторы
Добавили Behaviour для валидации
Вызываем
services.AddCustomMVC(Configuration)в котором происходит регистрация валидаторовНу и дальше уже DI все сам разрулит
Inject вроде бы объявлен deprecated. Не нашлось ли у Вас ему адекватной замены для обеспечения строго типизации?
Возможно я чего-то не понимаю, но не могли бы Вы пояснить, почему Вы использовали такую конструкцию, а не механизм await:
Если отключить в браузере JS, то подавляющее число веба становится недоступным :)
Насколько трудоёмким будет переход с того же OpenCL на oneAPI и какие преимущества от этого можно будет получить?
Тут, мне кажется, больше проблема в том, что новички (и я в их числе) в поисках best practices встречаются с популярными, но не самыми лучшими архитектурными решениями.
Лично я в своем проекте использовал пример работы с OpenDota API и уже в процессе работы наткнулся на недостатки, озвученные Вами.
Спасибо за статью)
Интересно было бы еще узнать, как быть в случае с redux. Есть ли способы так же единообразно обрабатывать ошибки? Да, почти вся логика уходит в action-ы и reducer-ы, что позволяет обрабатывать их императивно, но при написании тех же запросов получения данных появляется довольно много бойлерплейта.
Была идея использовать отдельный action на обработку ошибок по http коду, а прочие исключение сводить к ним, но данное решение выглядит несколько криво, да и не особо удалось в силу того, что на беке ошибки контекстно зависели от запроса.
Интересно было бы сравнить различные варианты fallback-ов на больших данных.
Не могу не согласится, ибо у самого были случаи, когда находился пара пользователей с крайне специфичным железом :)
В данном вопросе больше ориентировался на предположение, что данный код будет исполняться на сервере.
Хотя при работе с интринсиками в первую очередь стоит ориентироваться на примерные характеристики целевого устройства (или набора устройств).