V
const
onSaveMock = jest.fn().mockResolvedValue(Promise.resolve());попробуй
mockReturnValue(Promise.resolve())Size: a a a
2021 February 24
Т
попробуй
mockReturnValue(Promise.resolve())Да не, должно и просто mockResolvedValue работать, у него где то еще ошибка
Т
const
onSaveMock = jest.fn().mockResolvedValue(Promise.resolve());Покажи весь тест и код компонента на gist
И какая ошибка
И какая ошибка
M
Покажи весь тест и код компонента на gist
И какая ошибка
И какая ошибка
M
на событие button onClick повешено событие onDeleteHandler все примитивно просто
КЛ
Есть некий компонент Product
Он занимается отображением данных о продукте, type ProductData
Есть некие настройки того, как отображается продукт. Например, какой тултип выводить у цен на продукт. Это тултип настраивается для всей витрины и один раз, он для всех продуктов одинаковый.
Собственно, вопрос - нужно ли мне класть текст тултипа в ProductData, собирая, условно, "всё что нужно компоненту Product в одну исчерпывающую модель" или будет норм кинуть отдельно ProductData компоненту и рядом бросить текст тултипа?
В первом случае меня смущает, что по-сути тултип - это не свойство продукта и в модели продукта ему делать нечего, плюс это дублирование одного и того же значениея в куче моделей, при том, что я 100% знаю что тултип всегда будет один
Во втором - то, что я возможно усложню всё таким разделением и это будет контр-интуитивно для будущих поколений
Что звучит более интуитивно понятно с первого раза?
Он занимается отображением данных о продукте, type ProductData
Есть некие настройки того, как отображается продукт. Например, какой тултип выводить у цен на продукт. Это тултип настраивается для всей витрины и один раз, он для всех продуктов одинаковый.
Собственно, вопрос - нужно ли мне класть текст тултипа в ProductData, собирая, условно, "всё что нужно компоненту Product в одну исчерпывающую модель" или будет норм кинуть отдельно ProductData компоненту и рядом бросить текст тултипа?
В первом случае меня смущает, что по-сути тултип - это не свойство продукта и в модели продукта ему делать нечего, плюс это дублирование одного и того же значениея в куче моделей, при том, что я 100% знаю что тултип всегда будет один
Во втором - то, что я возможно усложню всё таким разделением и это будет контр-интуитивно для будущих поколений
Что звучит более интуитивно понятно с первого раза?
Текст тултипа явно не относится к модели ProductData, смысла там хранить текст нет
Также можно разрулить композицией по типу
Также можно разрулить композицией по типу
<Product
tooltip={() => <MyTooltip text=“…” />}
/>Т
Это не весь код
M
Это не весь код
там сложно будет весь код скинуть тебе. т.к компонент в компоненте, громозкий будет(
Т
там сложно будет весь код скинуть тебе. т.к компонент в компоненте, громозкий будет(
Хотя бы как ты его рендеришь и что передаешь, на gist все влезет
M
Хотя бы как ты его рендеришь и что передаешь, на gist все влезет
вот так в рендере, кнопка удаления, просто пропс прокинут, из компонента выше
M
если уж так не понятно будет попробую на гист(
DM
Есть некий компонент Product
Он занимается отображением данных о продукте, type ProductData
Есть некие настройки того, как отображается продукт. Например, какой тултип выводить у цен на продукт. Это тултип настраивается для всей витрины и один раз, он для всех продуктов одинаковый.
Собственно, вопрос - нужно ли мне класть текст тултипа в ProductData, собирая, условно, "всё что нужно компоненту Product в одну исчерпывающую модель" или будет норм кинуть отдельно ProductData компоненту и рядом бросить текст тултипа?
В первом случае меня смущает, что по-сути тултип - это не свойство продукта и в модели продукта ему делать нечего, плюс это дублирование одного и того же значениея в куче моделей, при том, что я 100% знаю что тултип всегда будет один
Во втором - то, что я возможно усложню всё таким разделением и это будет контр-интуитивно для будущих поколений
Что звучит более интуитивно понятно с первого раза?
Он занимается отображением данных о продукте, type ProductData
Есть некие настройки того, как отображается продукт. Например, какой тултип выводить у цен на продукт. Это тултип настраивается для всей витрины и один раз, он для всех продуктов одинаковый.
Собственно, вопрос - нужно ли мне класть текст тултипа в ProductData, собирая, условно, "всё что нужно компоненту Product в одну исчерпывающую модель" или будет норм кинуть отдельно ProductData компоненту и рядом бросить текст тултипа?
В первом случае меня смущает, что по-сути тултип - это не свойство продукта и в модели продукта ему делать нечего, плюс это дублирование одного и того же значениея в куче моделей, при том, что я 100% знаю что тултип всегда будет один
Во втором - то, что я возможно усложню всё таким разделением и это будет контр-интуитивно для будущих поколений
Что звучит более интуитивно понятно с первого раза?
не совсем было понятно, но все же, если у будущем планируеться изменения текста для тултипов, то лучше будет передавать через props, но нужно будет еще поставить по дефолту текст, в случае если не указали текст, это при условии что везде должен быть тултип, если же будут кейсы когда его нету, то можно через props передавать тултип, в котором будет уже сам туллтип реализовывающий какой то свой функционал
про разделение, кажеться имеете ввиду, про разбиение интерфейса на более мелкий код, на фронте это нормально, но всеже зависит от проекта и договоренности на нем
про разделение, кажеться имеете ввиду, про разбиение интерфейса на более мелкий код, на фронте это нормально, но всеже зависит от проекта и договоренности на нем
Т
Крч, я все, устал у тебя вытягивать. Где то ты ошибся и не замокал функцию которая возвращает промис
M
Крч, я все, устал у тебя вытягивать. Где то ты ошибся и не замокал функцию которая возвращает промис
const
тоесть это должно работать в твоем понимании?
onDeleteMock = jest.fn().mockReturnValue(Promise.resolve());тоесть это должно работать в твоем понимании?
N
Безопасно ли делать access токен долговечным (допустим на 50 лет) и не париться с refresh, если сайт хорошо защищен от XSS атак?
V
Безопасно ли делать access токен долговечным (допустим на 50 лет) и не париться с refresh, если сайт хорошо защищен от XSS атак?
если токен хранится в httpOnly same site куки то ничего плохого не вижу имхо
NJ
Безопасно ли делать access токен долговечным (допустим на 50 лет) и не париться с refresh, если сайт хорошо защищен от XSS атак?
А причём тут xss?
N
А причём тут xss?
ну вдруг захотят токен украсть