ŹR
Лучше уже with
Size: a a a
2021 January 03
LL
Лучше уже with
И
when not is_nil, да?IK
Ничем, лично я в своём коде избегаю
А так, эрлангисты весь этот
Например,
nil-овА так, эрлангисты весь этот
with декомпозируют в функции и матчатся в нихНапример,
def update_username(id, newname) do
id
|> do_get_user()
|> do_update_username()
end
defp do_get_user(nil), do: nil
defp do_get_user(id), do: User.get(id)
defp do_update_username(nil, _), do: nil
defp do_update_username(user, name), do: User.update(user, name: name)
Не люблю такой подход. Парочку раз видел более извратный вариант
def foo({:ok, car}), do: :bar
Ну и эррор обработка.
И это все в пайпинге...
Мне нравится рекомендация из эрланг гайдлайна на этот счёт - в core ядре доверять типам инпутов в функциях
def foo({:ok, car}), do: :bar
Ну и эррор обработка.
И это все в пайпинге...
Мне нравится рекомендация из эрланг гайдлайна на этот счёт - в core ядре доверять типам инпутов в функциях
ŹR
Самый сок в with - это когда в нескольких местах одинаковый fail path и надо залогать.
И тогда ты пишешь что-то типа
with {:name, name} <- {:name, get_name()}
И тогда ты пишешь что-то типа
with {:name, name} <- {:name, get_name()}
ŹR
Чтобы потом в else заматчить где именно упало
LL
Не люблю такой подход. Парочку раз видел более извратный вариант
def foo({:ok, car}), do: :bar
Ну и эррор обработка.
И это все в пайпинге...
Мне нравится рекомендация из эрланг гайдлайна на этот счёт - в core ядре доверять типам инпутов в функциях
def foo({:ok, car}), do: :bar
Ну и эррор обработка.
И это все в пайпинге...
Мне нравится рекомендация из эрланг гайдлайна на этот счёт - в core ядре доверять типам инпутов в функциях
Ну это-то понятно, но тут разговор о том, как хэндлить
result :: any() | nil, вместо {:ok, result :: any()} | :errorAß
Самый сок в with - это когда в нескольких местах одинаковый fail path и надо залогать.
И тогда ты пишешь что-то типа
with {:name, name} <- {:name, get_name()}
И тогда ты пишешь что-то типа
with {:name, name} <- {:name, get_name()}
и после этого кто-то ещё говорит что with не говно
AB
я как-то делал хелперы для with, совсем не такие, но чем-то по духу похожие, типа
def with_not_nil(nil, key), do: {:error, {key, nil}}
def with_not_nil(v, key), do: {key, v}
...
with {:a, a} <- Map.get(x, "a") |> with_not_nil(:a)
...Вот там я постил про with и хэлперы к нему, код довольно приятный получался
AB
A ß
и после этого кто-то ещё говорит что with не говно
Главная проблема with в том, что он не позволяет легко перейти от одной ошибки к сбору всех ошибок
AB
А так нормальный тул для разгребания входящих данных на коленке
LL
A ß
и после этого кто-то ещё говорит что with не говно
А что не так с
with-то?Aß
А что не так с
with-то?выглядит как говно, работает как говно
LL
Главная проблема with в том, что он не позволяет легко перейти от одной ошибки к сбору всех ошибок
Мне кажется, что если хочется обрабатывать ошибки от разных
<- по-разному, то лучше всё вынести в различные функции простоLL
A ß
выглядит как говно, работает как говно
Так ты конкретное что-нибудь скажи
Aß
Так ты конкретное что-нибудь скажи
куда конкретнее?
LL
Мне кажется, что если хочется обрабатывать ошибки от разных
<- по-разному, то лучше всё вынести в различные функции простоНу вот как можно лучше сделать? Чего не хватает?
AB
Мне кажется, что если хочется обрабатывать ошибки от разных
<- по-разному, то лучше всё вынести в различные функции простоЯ не думаю, что единый кусок логики "достать проекцию В из куска данных А" стоит размазывать на несколько функций
B
with - уж полюбому лучше чем nested case городить.
B
А в инных случаях он не нужен. ИМХО конечно же 🙂
2021 January 04
TC
Почему в доках Phoenix нет деплоя через Docker?
Прямолинейный подход упирается в необходимость знать DATABASE_URL на этапе сборки образа, а я хочу задавать её при запуске образа... Если есть толковый гайд, дайте, пожалуйста
Прямолинейный подход упирается в необходимость знать DATABASE_URL на этапе сборки образа, а я хочу задавать её при запуске образа... Если есть толковый гайд, дайте, пожалуйста