Добрый вечер. Я понял что map это массив,а у меня обьект.Как код исправить?

Ребят, а зачем мне null в реальной жизни? MDN и null vs undefined читала. В практике обычно или строки или initial number. Когда у меня появляется необходимость использовать null?

Когда нужно например сказать что поле не заполнено, и надо разделять пустую строку и незаполненное поле (например представленное через null). Да и вообще часто используется, странные вопрос у вас однако

Object.keys(myObject)/for in/Object.entries

Object.keys(myObject)/for in/Object.entries

Спасибо

Добрый вечер. Я понял что map это массив,а у меня обьект.Как код исправить?

если промаппировать объект, то lodash вроде умел красиво

если промаппировать объект, то lodash вроде умел красиво

Спасибо буду гуглить в этих направлениях

Ребят, чот раньше HMR у меня работал без вот этого вот if (module.hot) {...}, а теперь отказывается. Что-то поменялось или я по-другому что-то делаю? Вроде всё как раньше. Подскажите

Когда нужно например сказать что поле не заполнено, и надо разделять пустую строку и незаполненное поле (например представленное через null). Да и вообще часто используется, странные вопрос у вас однако

да вот я и пытаюсь понять, а когда мне действительно нужно разделять пустую строку от незаполненного. Код не ломается. Что мне это даёт? От чего уберегает?

да вот я и пытаюсь понять, а когда мне действительно нужно разделять пустую строку от незаполненного. Код не ломается. Что мне это даёт? От чего уберегает?

Когда нужно знать например что поле или никогда не было заполнено или было, но потом значение удалили и осталась пустая строка

Когда нужно знать например что поле или никогда не было заполнено или было, но потом значение удалили и осталась пустая строка

Реальные случаи, навскидку вот припомнить не могу, но было необходимо мне на практике

Реальные случаи, навскидку вот припомнить не могу, но было необходимо мне на практике

вот, я пока свои грабли не нашла, а интересно. Если что вспомните — киньте в меня. Спасибо

Ну пустота и неизвестность это как минимум семантика думаю

При обновлении данных например, undefined может означать оставить значение поля без изменений, а null или пустая строка соотвественно изменить в то или иное значение

Вопрос в семантике, как уже заметили выше, отсутствие значения и пустое значение - разные кейсы

Вы можете спроектировать API где данные различия не будут присутствовать

Но возможно и обратное

Ну вот да, я пока вижу только семантическую заглушку для данных, которые пока не хочется задавать. На практике обычно сразу указываю данные по типу [], “”, 0

null и undefined разные, а вот использование null вместо пустых данных нужного типа это вопрос почему

Ну вот да, я пока вижу только семантическую заглушку для данных, которые пока не хочется задавать. На практике обычно сразу указываю данные по типу [], “”, 0

Ну вот есть у нас данные загружаемые с сервера, например user, логично же что до того как они будут получены user будет равен null, вы же не зададите его в {}, вот пример где нужен нулл

null и undefined разные, а вот использование null вместо пустых данных нужного типа это вопрос почему

undefined это отсутствие ключа или неопределенные данные а null это вполне ожидаемая ситуация, когда данных нет, и логика это предполагает

undefined это отсутствие ключа или неопределенные данные а null это вполне ожидаемая ситуация, когда данных нет, и логика это предполагает

а почему не сразу пустые данные? если мы типизируем тем более и ожидаем знаем что

Не обязательно, нет данных это скорей undefined, а null это значение, хоть и пустое

null is an assigned value. It means nothing. undefined typically means a variable has been declared but not defined yet.

null is an assigned value. It means nothing. undefined typically means a variable has been declared but not defined yet.

О чем я и написал выше

у меня скорее вопрос null vs [], “”, {}

у меня скорее вопрос null vs [], “”, {}

Зависит от опять же, если у вас скажем есть коллекция объектов, то естественным дефолтным значением будет []

у меня скорее вопрос null vs [], “”, {}

Вот вам пример

Запись в бд

Имя пользователя пустая строка

И его нет

Если же у вас единственный объект, 6 может быть пока не загруженный то дефолт естественно в null задать

1 случай это "" Второй это null

у меня скорее вопрос null vs [], “”, {}

{} в случае js вообще плохо, как будете проверять на empty?

{} в случае js вообще плохо, как будете проверять на empty?

Разве что objects keys))

{} в случае js вообще плохо, как будете проверять на empty?

_.isEmpty

Если со списком можно list.length то для {} все сложнее

_.isEmpty

Или так)(

_.isEmpty

Ну тянуть лодашь

Ну тянуть лодашь

он не проверит такое {123:undefined}

_.isEmpty

интересно, как будет с enumerable: false?

интересно, как будет с enumerable: false?

там вроде for in

интересно, как будет с enumerable: false?

Вот по этому я и сказал что не надо пустой объект как пустое значение использовать ибо проверка в ад превратится

Это не питон

он не проверит такое {123:undefined}

А потом гадать как в таких corner cases вести себя будет

я просто не юзал лоудаш, и стараюсь код писать что он был предсказуемый

там вроде for in

ну и типизация в помошь, хотя конечно в рантайме она не поможет 🙂

я просто не юзал лоудаш, и стараюсь код писать что он был предсказуемый

Я о том же, не то что бы я против лодаш, но вот такие методы как isEmpty от туда не очень интутитвыны

Запись в бд

make sense, надо осмыслить насколько мне нужна эта разница. Спасибо

Осталось выяснить Что скрывается за всеми этими isArrayLike

Предсказуемость и интуитивность не очень

ну и типизация в помошь, хотя конечно в рантайме она не поможет 🙂

За типизацию поддержу, мой опыт с flow, а сейчас с ts говорит, что данные инструменты позволяют избежать тонн примитивных ошибок, а при грамотном использовании и глубокой типизации и не очень и очень нетривиальных

тут сейчас за TS заплюют 😁

тут сейчас за TS заплюют 😁

Ох не знал ) недавно тут

Удалить чтоль пока не поздно сообщение

https://t.me/why_typescript_is_bad

https://t.me/why_typescript_is_bad

Честно говоря представляю что там. Я не первый день с ним и ступал по граблям, иногда хочется конечно и даже нуждаешься в скажем existansional data types но приходится костылить. Но все равно я останусь тут при своём мнении, что ts спасает от кучи ошибок.

есть же еще прекрасный f l o w

Честно говоря представляю что там. Я не первый день с ним и ступал по граблям, иногда хочется конечно и даже нуждаешься в скажем existansional data types но приходится костылить. Но все равно я останусь тут при своём мнении, что ts спасает от кучи ошибок.

а почему предпочел не flow? (открываю ящик пандоры, но мне интересно)

есть же еще прекрасный f l o w

Я начинал с него, но ts по ряду причин оказался выше него в моем списке приоритетов, так что в проектах за которые я отвечаю теперь все на нем

Я начинал с него, но ts по ряду причин оказался выше него в моем списке приоритетов, так что в проектах за которые я отвечаю теперь все на нем

я с ироней про flow говорю если что 🙂

Я начинал с него, но ts по ряду причин оказался выше него в моем списке приоритетов, так что в проектах за которые я отвечаю теперь все на нем

можно узнать ряд причин?

Object.keys(obj).length не проще?

можно узнать ряд причин?

как минимум вероятность найти тайпинги от стороних либ намного выше на TS

а почему предпочел не flow? (открываю ящик пандоры, но мне интересно)

Много субъективного =не очень, начиная с поддержки в vscode (кто пытался там с флоу работать тот поймет) и заканчивая тем, что флоу это как бы сбоку бантик, костыль, в итоге язык превращается в непонятную кашу, не понятно на каком языке ты пишешь. Этот Babel и куча плагинов к нему, надо помнить что надо тут добавить скажем rest spread transform plugin и так далее. То есть нельзя сказать что у меня питон 3.6 скажем, тут надо упомянуть что у нас ещё куча трансформаций для неких ecma proposals

Кстати

Object.keys(obj).length не проще?

Хз, предпочёл бы не проверять что объект пустой в жс вообще

Ещё JSON stringify + сравнение на '{}' *supermind*

Хз, предпочёл бы не проверять что объект пустой в жс вообще

Ещё не приходилось сравнивать

Ещё JSON stringify + сравнение на '{}' *supermind*

Кстати этот метод я использовал ´)

Ещё JSON stringify + сравнение на '{}' *supermind*

Надмозг или нет не знаю, но работает

Надмозг или нет не знаю, но работает

Затратное вроде

Если ещё объект оказался не пустым

А гигантский

если уж точно хотите то Object.values(obj).every((value) => yourCustomCheck(value))

Затратное вроде

У меня было при проверке результата запроса на удаление, редкое действо в моем приложении, так что на произвотельность пофиг.

если уж точно хотите то Object.values(obj).every((value) => yourCustomCheck(value))

Ключ может быть 0, false

Undefined

Ключ может быть 0, false

тогда Object.entries