pasaran / descript2 Goto Github PK

options.valid_params нужны были ровно для одной цели: не отправлять целиком все params целиком в query http-блока. По-дефолту, все params валятся в query.
Что хочется сделать:

1. Поменять дефолтное поведение. Ничего не слать в query по-дефолту.
2. Функцию options.valid_params заменить на такое же, но в block.query:

//  Было
de.http({
    options: {
        valid_params: {
            id: null,
        },
    }
})

//  Стало
de.http({
    block: {
        query: {
            id: null,
        },
    },
})

Для не-http блоков valid_params вроде вообще неактуально. А для http-блоков довольно часто вообще ничего в query слать не нужно и сейчас приходится писать query: {}.
А в новом варианте все будет в одном месте — в query. Тут явно указываем, что и как слать в query (по-дефолту — ничего).

https://github.com/pasaran/descript2/blob/master/lib/de.block.js#L570

поэтому нельзя сделать

select: {
    id: '.result.id'
}

а только

select: {
    id: function (params, context, state, result) {
        return result.id;
    }
}

Сейчас всякие options.before, options.after, options.result и т.д. имеют такие сигнатуры:

    (params, context, state)
    (params, context, state, result)
    (params, context, state, error)

И раньше это было, видимо, какая-то оптимизация. Типа 4 параметра дешевле передать, чем один объект. Кажется, сейчас это уже не так актуально, а сильно проще было бы писать так:

    after: function({ result }) {
        //  Do something with result
    },

Не нужно будет помнить, в каком там точно порядке идут эти 4 параметра. И использовать только то, что нужно.

Сейчас state единственный способ организовать общение и передачу информации между вызовами блоков. Но это по сути глобальные переменные, чистый анти-паттерн. И очень много неявных действий.
Кажется, что можно сделать совсем по-другому. Идея из #15.

Было

module.exports = {

    foo: block1({
        options: {
            id: 'foo',
            select: {
                some_id: de.jexpr('.result.foo.bar.id'),
            },
        },
    }),

    bar: block2({
        options: {
            deps: 'foo',
            params: {
                some_id: de.jexpr('state.some_id'),
            },
        },
    }),

};

Стало 1

module.exports = function() {
    const id = Symbol();

    return {
        foo: block1({
            options: {
                id: id,
            },
        }),

        bar: block2({
            options: {
                deps: id,
                params: {
                    //  В общем какой-то хелпер, чтобы получить результат блока с id: id.
                    //  some_id: ({ context }) => context.select(id, '.result.foo.bar.id'),
                    some_id: ({ deps }) => no.jpath('.result.foo.bar.id', deps[ id ]),
                },
            },
        }),

    };
};

Стало 2

module.exports = function() {
    const id = Symbol();

    //  Накрайняк можно явно завести локальный стейт.
    const state = {};

    return {
        foo: block1({
            options: {
                id: id,
                after: ({ result }) => state.foo = result,
            },
        }),

        bar: block2({
            options: {
                deps: id,
                params: {
                    some_id: () => no.jpath('.foo.result.foo.bar.id', state),
                },
            },
        }),

    };
};

Есть странная задача, выставлять в какой-то http-заголовок текущее значение таймаута.
Как это сделать — непонятно. И таймауты, и заголовки лежат в request_options и вычисляются в неопределенном порядке. Так что в момент вычисления заголовков получить значение таймаута — ну это будет костыль.
Видимо, нужен специальный хук, который уже готовые request_options примет и вернет новые.

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

Пример 1

module.exports = {
    foo: block1({
        options: {
            id: 'foo',
        },
    }),
    bar: block2({
        options: {
            deps: 'foo',
        },
    }),
};

Тут проблема в том, что если этот блок будет вызываться в одном контексте с разными параметрами (вполне реальный случай), то все сломается. Так как будет два блока с одним id в одном контексте.

Пример 2

module.exports = block({
    options: {
        id: 'foo',
    },
});

Тут проблема в том, что в том месте, где будет использоваться этот блок, не очевидно, что у него вообще есть id. И может случайно это как-то выстрелить. Например, в страничном блоке уже будет еще один блок с таким id.

Пример 3

module.exports = block({
    options: {
        deps: 'foo',
    },
});

Тут как и в примере 2, но по-другому. Тут наоборот, предполагается, что в месте использования кто-то догадается, что нужно в этом контексте запустить блок с id: 'foo'.

Вариант решения

Кажется, что за 2. и 3. нужно просто бить по голове во время ревью.
Но можно и усложнить стрелять себе в организм таким способом, запретив id-шники в виде строк, а разрешив только Symbol-ы (пока не реализовано).

И для 1. предлагается такой примерно вариант (опять же, все пока в мечтах):

//  Тут пока непонятно, или это просто de.func, или отдельная конструкция "динамического блока".
//  Соответственно сигнатура может быть (params, context, state) как обычно, или ничего.
module.exports = function() {
    const fooId = Symbol();

    return {
        foo: block1({
            options: {
                id: fooId,
            },
        }),
        bar: block2({
            options: {
                deps: fooId,
            },
        }),
    };
};

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

Ну и в 2. и 3. это тоже поможет. Потому что даже если написать так:

const fooId = Symbol();

module.exports = block({
    options: {
        deps: fooId,
    },
});

то надо будет как-то затейливо еще и передать этот fooId наружу. Как минимум это проще будет заметить на ревью.