Как стать автором
Обновить
1
0
Леготкин Алексей @ThisMan

Пользователь

Отправить сообщение

Сторибук и редакс девтулз хорошие инструменты. Плюс еще redux-promise-middleware-times можно использовать в девсборке для замеров скорости. Остальное уже кажется вторичным

Да и вообще, почему бы тем же движкам не выпустить свои инструменты для оптимизации?
Например, какие-то особо важные участки помечать специальным комментарием, а не какой-то конструкцией

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

Интересно, что есть такого у Optimize.js, чего нет у движков браузера, если первый может понимать, когда нужно оптимизировать функцию, а вторые нет?

Проблема ( как минимум с вебом ) это то что он еще не готов к такому бурному росту/изменению. Берешь какой-нибудь проект, который начинался в 2010, когда еще не было всяких es6, когда стандарты не выпускались каждый год и там дремучий древний лес. Как-то обновлять это — легче переписать с самого начала. Возможно, со временем, если скорость изменений языка/стандартов будет сохранятся, будут придуманы инструменты, для более безболезненного перехода на новые фичи языка.


Ну и да, какие-то монструозные проекты по определению столкнутся с тем, что в какой-то момент масштабировать их будет невозможно, просто из-за количества кода. И тут тоже нужно думать и искать новые подходы/архитектуру. Модульность — как хорошее начало, когда ты можешь взять и переписать один конкретный модуль и в идеале остальной проект даже не заметит это.

Ничего не мог с собой поделать, но все время читал HOC по-русски)

Тогда оказалось, что 13% респондентов ответили «Да», 83% — «Нет», а 4% выбрали вариант «Другое (в комментариях)».

На момент написания комментария расклад такой: 13.5% — "да", 82% — "нет", остальные не определились. Ну, хоть какое-то, но движение вперед есть)

Не давно проходил собеседование в Яндекс на разработчика интерфейсов. Собеседованием остался доволен, на первом этапе спрашивали солянку из html, css и особенностей javascript, ничего сверхъестественного и заковыристого. На следующем этапе было 4 интервью, которые были в виде практических задач. Совсем чуть-чуть теории спрашивали, а потом решали задачи. Считаю это самым правильным вариантом. Кандидат прекрасно может знать структуры данных, крутые алгоритмы и прочие теоретические вещи, но какой в этом толк, если он не может применить их на практике. Конкретные задачи как раз помогают выяснить, что умеет и знает кандидат. Как он подходит к решению проблемы, какие алгоритмы и структуры данных использует. Ведь в итоге именно за этим и ищут человека, что бы он решал конкретно поставленные задачи, а не хвастался, что знает все алгоритмы обхода графа

В других языках не так что ли? Все эти компиляторы, SDK конфигурируются одной кнопкой, что даже ребенок может справиться с этим?

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

Может я в маленьком городе живу, но ни разу не встречал на улице человека, который бы шел и ел. А места где продается фастфуд обычно оснащены местами, где этот фастфуд можно употребить, следовательно, к чему так зацикливаться на то, что бы еду можно было именно есть на ходу/в спешке. А если нет, то все сводится к обычной столовой, которая чуть более мобильна

webpack двигается в сторону полноценного SDK для веб приложений

Если я правильно понял задание с массивом, то нам нужно просто посчитать индексы значений, которые меньше k, получим массив (пример) [0, 1, 3, 4], а потом пройдем циклом по элементам и если следующий индекс больше предыдущего на 2 и больше, значит нужна перестановка.


Код на js
const array = [2, 7, 9, 5, 8, 7, 4]
const k = 5

const groupNearK = function (arr, k) {
    const length = arr.length
    const idx = []
    let moveCount = 0

    for(let i = 0; i < length; i++) {
        if(arr[i] <= k) idx.push(i)
    }

    for(let i = 1; i < idx.length; i++) {
        if((idx[i] - idx[i - 1]) > 1) moveCount++
    }

    return moveCount
}

console.log(groupNearK(array, k))

Решение за один цикл
const array = [2, 1, 5, 6, 3]
const k = 3

const groupNearK = function (arr, k) {
    const length = arr.length
    let moveCount = 0
    let lastIndex = -1

    for(let i = 0; i < length; i++) {
        if(arr[i] <= k) {
            if(lastIndex >= 0 && (i - lastIndex) > 1) {
               moveCount++
            }

            lastIndex = i
        }
    }

    return moveCount
}

console.log(groupNearK(array, k))

Решается в один цикл


Код на js
let result;

for(let i = 50; i <= 100; i++) {
    if(
        (i % 2 === 0) &&
        (i % 3 === 0) &&
        (i % 5 === 3)
    ) {
        result = i
    }
}

console.log(result)

Пример с React и state в первом пункте не совсем правильный. Ошибкой будет


Cannot read property 'items' of null

так как явно не указан state, а по умолчанию он равен null

Вам еще не надоело хаить инструменты? Тут ведь все сводиться к делу вкуса: кто-то любит низкоуровневый Redux, где ты контролируешь весь поток данных, кто-то любит абстракции и магию, не задумываюсь о реализации всего этого. Но с чего это ваши личные предпочтения вдруг делают %инструмент_нейм% ужасным, неэффективным и вообще использование его становится моветон. Есть же альтернативы, так используйте их, зачем писать эти статьи? Я как новичок из них ничего не получу, так как легко могу найти статьи за и против любого инструмента. Все равно придется пробовать самому.
Кому-то нравится электродрель, кому-то молоток и гвозди, а кому-то легче нанять рабочих и вообще не париться.

Отдельных верстальщиков нет, точнее есть, но они в других проектах, а там уже не известно используют они React или нет. На нашем проекте вставал вопрос о разделении на верстальщика и разработчика фронта, но потом поняли, что это избыточно.

Какая-то реклама собственного фреймворка, на основе унижения React-а.
Участвую в проекте разработки CRM, пишем на React-е, есть огромная библиотека простых виджетов/ui-компонентов, которые используются/переиспользуются вполне благополучно. Да, тем кто раньше писал только ООП сложно поменять парадигму и перейти на функциональных подход к компонентам, поэтому все еще используют наследование и перегрузку методов, вместо HOC, но это лечится)

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


Пример c counter
const COUNTER_INCREMENT = "counter increment"
const COUNTER_DECREMENT = "counter decrement"
const COUNTER_INIT = "counter init"

const getInitialCounter = ({
    counter: 0
})

const counter(initialState = {}, action) {
    const {payload, type} = action;

    switch(type) {
        case COUNTER_INIT: {
            const {name} = payload

            return {
                ...state,
                [name]: getInitialCounter()
            }
        },
        case COUNTER_INCREMENT: {
            const {name} = payload
            const oldCounter = state[name]
            const updatedCounter = {
                counter: oldCounter.counter++
            }

            return {
                ...state,
                [name]: updatedCounter
            }
        }
        case COUNTER_DECREMENT: {
            const {name} = payload
            const oldCounter = state[name]
            const updatedCounter = {
                counter: oldCounter.counter--
            }

            return {
                ...state,
                [name]: updatedCounter
            }
        }
        default return state;
    }
}

const incrementCounter(name) => ({type: COUNTER_INCREMENT, name})
const decrementCounter(name) => ({type: COUNTER_DECREMENT, name})
const initCounter = (name) => ({type: COUNTER_INIT, name})

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

Звучит как какое-то будущее, где приложения меняются визуально в зависимости от внешних факторов: утром цвета яркие, сочные, что бы взбодрить меня, ближе к вечеру становятся нейтральными, что бы глаза не уставали и т.д. Пусть еще анализируют элементы по которым я чаще всего кликаю/тапаю что бы располагать их ближе друг к другу или более оптимально. Вообще тут много и долго можно фантазировать и идея действительно интересная
Важен не размер, а вращение в векторном пространстве


Теперь у меня есть отговорка перед девушками)

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность