Интересно, чем автору не угодил подход с использованием OpenAPI? Неужели настолько интереснее городить троллейбус из буханки, используя bit или что-то подобное? )
И предложение использовать BFF для решения проблемы - тоже, мягко говоря, достаточно странное: BFF - он, как бы, вообще не про это. Да и решением это трудно назвать: имели одну проблему - синхронизацию типов api фронта и бэка, получили две проблемы - синхронизацию типов api фронтенд-bff и bff-бэкенд.
Вроде бы и всё прекрасно, и за Next.js хочется только порадоваться, но в процессе чтения статьи, продираясь сквозь воды восторга, иногда ловишь себя на мысли, что попал в какой-нибудь очередной телемагазин, где тебе предлагают выгодно приобрести очередную очень нужную штуку )
Но если по существу, то да: ребята молодцы, очередной раз показали, что нет предела совершенству, что всегда есть куда расти. И теперь уже даже чисто из спортивного интереса не терпится узнать, каким же будет следующий этап развития )
Каждая строчка в таблице представляет собой уникальное начальное условие (где был приз и какую дверь выбрали) и два варианта исхода в зависимости от решения о смене двери. Для наглядности и экономии места я не стал делать отдельную строку для каждого исхода, а расположил их в колонках. Как мне кажется - строки вполне независимы друг от друга. Если объясните поподробнее, в чем я ошибся - буду крайне признателен.
Все верно, так и хотел сделать сначала, но для наглядности решил привести полностью все возможные варианты, чтобы уж точно не было подозрений в какой-либо подтасовке )
Если уж играться с табличками, то не обязательно при этом использовать тысячи рандомных игр - достаточно просто заполнить её всеми возможными комбинациями - тогда сразу увидим, какова вероятность выигрыша в случае замены и не-замены двери.
Хорошая, нужная статья, много правильных мыслей, хоть и есть несколько спорных моментов: например, совершенно непонятно зачем приплетён useCallback, который вообще совсем для другого, да и аргументы против генерации формы из конфига довольно странные, т.к. решаемая здесь задача этого вообще не предполагает (к тому же, повторное использование InputField с разными параметрами никак не противоречит DRY). Генерация форм — это вообще совершенно другая задача, которая должна решаться не здесь, а где-то на других уровнях абстракции, если уж вдруг возникнет необходимость в реализации именно такого подхода.
Ну и если уж всё это претендует туториал с примерами реального, а не псевдо-кода, то этот код лучше, наверное, сделать рабочим? В начале статьи всё было правильно, но после рефакторинга куда-то потерялся мерж с текущим стейтом.
// handleChange курильщика.
// В отличии от классового setState(),
// здесь потеряются все данные стейта,
// кроме назначаемого текущего поля.
const handleChange = fieldName => fieldValue => {
setLogInData({
[fieldName]: fieldValue,
});
};
// handleChange здорового человека.
// Вот тут все будет работать правильно
const handleChange = fieldName => fieldValue => {
setLogInData({
...logInData,
[fieldName]: fieldValue,
});
};
Интересно, чем автору не угодил подход с использованием OpenAPI? Неужели настолько интереснее городить троллейбус из буханки, используя bit или что-то подобное? )
И предложение использовать BFF для решения проблемы - тоже, мягко говоря, достаточно странное: BFF - он, как бы, вообще не про это. Да и решением это трудно назвать: имели одну проблему - синхронизацию типов api фронта и бэка, получили две проблемы - синхронизацию типов api фронтенд-bff и bff-бэкенд.
Вроде бы и всё прекрасно, и за Next.js хочется только порадоваться, но в процессе чтения статьи, продираясь сквозь воды восторга, иногда ловишь себя на мысли, что попал в какой-нибудь очередной телемагазин, где тебе предлагают выгодно приобрести очередную очень нужную штуку )
Но если по существу, то да: ребята молодцы, очередной раз показали, что нет предела совершенству, что всегда есть куда расти. И теперь уже даже чисто из спортивного интереса не терпится узнать, каким же будет следующий этап развития )
Каждая строчка в таблице представляет собой уникальное начальное условие (где был приз и какую дверь выбрали) и два варианта исхода в зависимости от решения о смене двери. Для наглядности и экономии места я не стал делать отдельную строку для каждого исхода, а расположил их в колонках. Как мне кажется - строки вполне независимы друг от друга. Если объясните поподробнее, в чем я ошибся - буду крайне признателен.
Все верно, так и хотел сделать сначала, но для наглядности решил привести полностью все возможные варианты, чтобы уж точно не было подозрений в какой-либо подтасовке )
Если уж играться с табличками, то не обязательно при этом использовать тысячи рандомных игр - достаточно просто заполнить её всеми возможными комбинациями - тогда сразу увидим, какова вероятность выигрыша в случае замены и не-замены двери.
Ну и если уж всё это претендует туториал с примерами реального, а не псевдо-кода, то этот код лучше, наверное, сделать рабочим? В начале статьи всё было правильно, но после рефакторинга куда-то потерялся мерж с текущим стейтом.
Быстрая настройка подсветки файлов и папок из контекстного меню, без объявления скоупов и вот этого всего.