05.11.2023, 15:50
|
Профессор
|
|
Регистрация: 06.01.2012
Сообщений: 409
|
|
Основные Web API
Web API очень много развелось
(смотрел MDN)
Накидайте основных, которые надо знать.
Типа Geolocation, localstorage и тд...
|
|
05.11.2023, 19:14
|
|
Профессор
|
|
Регистрация: 30.04.2012
Сообщений: 3,018
|
|
Да сами АПИ все запоминать смысла нет
Просто важно знать какие есть возможности у браузера и всегда уметь загуглить
Все зависит от специфики продукта, который вы разрабатываете
В классическом SPA важно знать инструкменты и фреймворки, нежели чем Web API.
Из основного/интересного я бы почитал: Web Workers, RedizeObserver. Intersection Observer. Proxy, CSS Painting, View Transitions
|
|
06.11.2023, 09:59
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,742
|
|
Сообщение от torsar
|
которые надо знать.
|
Которые надо знать для чего? Конкретно для работы или для собеседований?
Для работы я ни разу не использовал Geolocation и толком не знаю его. Просто знаю, что такое есть. Для работы мне в голову не придет использовать CSS Painting и View Transitions потому, что их пока нет в файрфоксе и сафари.
Для работы надо познакомится со всеми, а использовать и хорошо знать только те, что реально используются. С остальными достаточно просто познакомится, что бы представлять, что они могут дать. Вдруг когда-нибудь пригодятся.
|
|
08.11.2023, 01:10
|
|
Профессор
|
|
Регистрация: 14.11.2014
Сообщений: 186
|
|
Сообщение от ruslan_mart
|
Да сами АПИ все запоминать смысла нет
Просто важно знать какие есть возможности у браузера и всегда уметь загуглить
|
Поддерживаю. Веб-технологии быстро развиваются. Какие-то появляются, какие-то устаревают. Важно следить за миром IT.
Первоначально отталкивайтесь от поставленной задачи. На основании этого будет ясно понять на какие API обратить внимание и что использовать в своём проекте.
- Используйте Can I Use для тестирования поддержки браузерами.
Вообще для работы с DOM и сетевыми запросами часто используются:
/*
*
Часто используется для работы с DOM и Request
*
*/
//1.
const items = document.querySelectorAll(''); // выбираем необходимые элементы, н-р, все ссылки на странице или какие-то блоки с определенным классом
//2.
items.forEach((element) => {}); // перебираем выбранные элементы из п.1 и работаем с каждым по отдельности
//3.
element.addEventListener('event', () => {}); // отлавливаем события конкретного элемента, например, когда на него нажали и т.д.
//4.
fetch(); // отправляем запрос по url — н-р, для работы со сторонними API
Главное чтоб у вас был интерес к выбранному API, потому что одну и ту же задачу можно решить разными способами. А интерес может как раз таки зависеть от скорости выполнения задачи и понятности кода. Поэтому стремитесь к реактивности и отказоустойчивости решения. Тестируйте разные варианты.
|
|
08.11.2023, 11:35
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,742
|
|
Сообщение от webgraph
|
items.forEach((element) => {}); // перебираем выбранные элементы из п.1 и работаем с каждым по отдельности
|
С таким же успехом можно использовать
for (const element of items) {
}
Как + не тратится время на вызов функции.
|
|
09.11.2023, 01:03
|
|
Профессор
|
|
Регистрация: 14.11.2014
Сообщений: 186
|
|
Сообщение от voraa
|
Как + не тратится время на вызов функции.
|
хм, интересненько) а если надо индекс еще, то как тогда?)
Плюсом со стороны forEach — это быстрое и наглядное понимание и чтение кода. Видно вначале, что это массив и что он перебирается.
Работа с forEach, более того, несколько последовательнее и от того проще)
Даже и не припоминается, когда последний раз for() использовался)
|
|
09.11.2023, 01:07
|
|
Профессор
|
|
Регистрация: 14.11.2014
Сообщений: 186
|
|
Сообщение от voraa
|
С таким же успехом можно использовать
|
а если надо массив налету создать?
['item1','item2'].forEach((e) => {
...
});
//P.S. достаточно часто такая конструкция используется
С помощью for() так тоже можно?)
|
|
09.11.2023, 07:55
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,742
|
|
Сообщение от webgraph
|
а если надо массив налету создать?
['item1','item2'].forEach((e) => {
...
});
|
[QUOTE=webgraph]Плюсом со стороны forEach — это быстрое и наглядное понимание и чтение кода. Видно вначале, что это массив и что он перебирается.[/QUOTE]
Дело привычки. Видно, что в цикле что то перебирается
|
|
09.11.2023, 13:20
|
|
Профессор
|
|
Регистрация: 30.04.2012
Сообщений: 3,018
|
|
Сообщение от webgraph
|
С помощью for() так тоже можно?)
|
Конечно
for (const item of ['item1','item2']) {
}
Но это быдлокод
Используйте forEach, нет смысла экономить на вызове функций, если вы не пишите ПО для очень слабых систем или какую-то библиотеку.
К тому же, есть вероятность, что в проекте for..of может транспилиться в другой код для поддержки совместимости, а это на выходе будет еще больше функций-оберток, нежели чем forEach.
Обычно for циклы полезны, чтобы сделать преждевременный break. Но опять же, зависит от конкретной задачи, так как может быть достаточно методов find/some.
|
|
09.11.2023, 13:44
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,742
|
|
Сообщение от ruslan_mart
|
К тому же, есть вероятность, что в проекте for..of может транспилиться в другой код для поддержки совместимости, а это на выходе будет еще больше функций-оберток, нежели чем forEach.
|
В этом случае и для forEach будет использоваться полифил, что тоже скажется на времени.
Ну и про наглядность - по мне вложенные for нагляднее, чем вложенные forEach (а по скорости еще лучше, т.к не тратится время на создание и компиляцию вложенной функции)
|
|
|
|