Pull to refresh
4
0
Антон Матренин @defint

Software Developer

Send message
Но нужно ли для маленького приложения писать собственные решения, которые давно сделаны в нескольких интерпретациях? Придумать пару десятков ключей выглядит более простой задачей.
Но в любом случае автору виднее)
А какие конкретно проблемы в существующих библиотеках (react-18next, например) вы нашли? Почему решили написать собственную обвязку? Что будет, если переводимых сообщений будет 1000, держать в памяти все все переводы? Что делать с поддержкой множественных чисел? Если поменяется содержание ключа словаря — нужно поиском по проекту искать все вхождения некорректной надписи?
Спасибо, надо проработать такой вариант.
Спасибо за замечание, но тогда бы пришли ненавистники англицизмов :)
Все верно, но что делать, когда количество зрителей будет более 100 человек? Я понимаю, что для первого раза вполне подошел бы и зум с нашим онлайном, но вот для второго митапа я не уверен, что хватит.

А как вы организовываете QA-сессию? Через сторонний сервис или используете чатик, встроенный в зум?
Есть еще украинское сообщество ArtFlutter. Чаще всего говорят на русском, но ивенты все на территории Украины.
А как дела обстоят с тест-отчетами?
Мы переопределяли flutter_drive для работы с JSONReporter, который формирует JUnit для каждого тестового файла, а потом при помощи node.js тулы генерирует html-отчет для вывода результатов тестов.

И еще вопрос по логированию и определения места, где тест упал. Может ли ваш TestAction сказать на каком именно экшене упал тест? Так как в нашем проекте очень сложно с формированием человекопонятных логов.
Еще интересный кейс с форматированием чисел.
Допустим вам надо вывести миллион в виде: 1 000 000. При dir=«rtl» получите — 000 000 1, хотя все числа на арабском не должны никак трансформироваться.
Особенно сложно отлавливать, когда изначально разделитель был ",".
Apollo GraphQL решает проблемы сайд эффектов, которые в большинстве проектах решает redux-saga.
Спасибо за статью. Хотелось бы подробностей о каждом проекте: почему думали что зайдет / почему не зашел / какие модели распространения были применены и тп. Если не секрет, конечно же.

В качестве замечания: было бы удобнее подавать в формате «иллюзия — опровержение», чем двумя отдельными списками.
Как решаете проблемы с тестирование на андроиде?
Возможно достучаться до элемента, если вместо testID вставлять accessabilityLabel. Но при таком подходе уже нельзя использовать testID для ios и приходится писать «platform specific code», где в элемент вставляется либо testID, либо accessabilityLabel.
Но даже в этом случае не соблюдается полная уникальность, так как идентификаторы наследуются в финальном дереве представления.
В том-то и проблема, что кому как повезет. У нас тоже были одобреные приложения даже без приветсвенного экрана, где был сразу логин/регистрация. А бывает вот такая ситуация, когда упираются в правила и все, никому ничего не докажешь.
Всего-то интеграция со сторонней базой данной, в которой аутентифкация по номеру телефона. Интеграция завязана на список продуктов и их цену, мы не может показывать «левым» пользователям специфические продукты, точно так же как и показывать полную стоимость тому, кто обычно покупает по скидке.
Возможно еще дело в самой специфике бизнеса и что это очень редкий случай, но приложение не имеет смысл без этой интеграции, поэтому приходится вставлять статический контент, которым по сути никто не будет пользоваться.
У нас уже раз 5 реджектили приложение, потому что оно запрашивает телефон пользователя сразу после вступительного скрина.
Каждый раз описываем им, что приложение не может работать без логина, так как завязано на внутренние интеграции, но всегда одна и таже отписка, что есть такое правило по которому пользователь должен работать с приложением без логина.
Вот собираемся добавить левый контент, не относящийся к основной функциональности приложения. Небольшой маразм.
Если API у роли полностью отличается, то это делается отдельным инстансом graphql (например, для админки и для пользователя полностью отличаются входные/выходные данные).
Если АПИ более-менее похожий, то разруливается на уровне резолверов.

Если используете Apollo, то вот есть статья, где расписывается как они работает через директивы: www.apollographql.com/docs/guides/access-control.html
1) банальный пример — корзина с продуктами: добавляем продукт на странице списка товаров — обновляем на странице с корзиной товаров. локальным стейтом тут не обойдешься, через сервер прогонять данные — не лучшее решение. конкретно в этом случае apollo-link-state подходит на 100%.
2) update хорош, но только когда у вас малое количество обновляемых данных. при росте приложения — растет количество мест, где надо думать об обновлении данных. открыли для себя `reFetchObservableQueries`, добавляет магии, но работает.
Спасибо за статью. Есть несколько вопросов:
1) Каким образом получилось полностью избавиться от redux? Пробовали apollo-link-state, но появляется много оверхеда (создать запрос, прочитать кеш, выполнить мутацию, записать в кеш).
2) Каким образом управляете частичной очисткой кеша? например пользователь оставил комментарий, поэтому надо не просто рефетчить текущий список, а и удалить из кеша счетчик комментариев у пользователя, например. А в другом месте начислить какие-то баллы за оставленный комментарий.
Если уж совсем от redux хочется избавится, то можно попробовать apollo-link-state (https://github.com/apollographql/apollo-link-state).
На данный момент мне не очень понравилась работа с кэшем, но обещают в новой версии добавить хелперы на все случаи жизни.
Мы используем подход оборачивания в функции. Подробнее можно почитать тут: medium.com/@defint/redux-actions-async-1b874630ce09
Например, один из уровней несет в себе составную логику, которую тоже было бы неплохо разделить (или как говорил один из известных людей: «Ухлубить!»). Но такого подхода нет в API Redux.

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

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

Information

Rating
Does not participate
Location
Украина
Registered
Activity