поэтому такая форма https://t.me/effector_ru/209179

мне кажется, что этого пояснения достаточно внутри какой-то конкретной команды разработчиков, если речь всё ещё про гипотетическое правило для линтера, а не про throw Error конечно :)

Да, резонно

просто только из неё можно вынести ценные наблюдения:

почему в таком-то проекте склонны использовать map on?
с какими задачами они сталкиваются?
то что они это используют — проблема недостаточной документации или апи библиотеки в принципе ограничен и они вынуждены?

так точка зрения поменялась после горячего обсуждения этого самого мап + он, и во многом благодаря твоему порицанию и зачаткам идей давить это в рантайме
https://t.me/effector_ru/94553

это известная техника, называется 5 why

https://www.mindtools.com/pages/article/newTMC_5W.htm

Have you ever had a problem that refused to go away? No matter what you did, sooner or later it would return, perhaps in another form.

Stubborn or recurrent problems are often symptoms of deeper issues. "Quick fixes" may seem convenient, but they often solve only the surface issues and waste resources that could otherwise be used to tackle the real cause.


https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.fivewhys.en.html

— Identify the problem
— Ask why the problem happened, and record the reason.
— Decide if the reason is the root cause
— Could the reason have been prevented?
— Could the reason have been detected before it happened?
— If the reason is human error, why was it possible?
— Repeat the process using the reason as the problem. Stop when you are confident that you have found the root causes.

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

это как-то связано с необходимостью указывать initialState в createStore и ситуациями, в которых это оказывается неудобно. подробности хотелось бы узнать и самому)

Да все верно. И то что даже сейчас мы продолжаем рассуждать исходя из вел ноун кейсов

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

А такой вариант? В целом, как в твоем примере:

const $token = createStore<T>('', {
  serialize: false | (t: T) => string;
  deserialize: (s: string) => T;
})

// игнорим
const $token = createStore<T>('', {
  serialize: false,
})

// кастомные правила
const $token = createStore<T>('', {
  serialize: (t: T) => string;
  deserialize: (s: string) => T;
})

Не уверен, разве что, насчет типизации тут 🤔
В целом, типизируется

Или:

const $token = createStore<T>('', {
  serialize: {
    omit: boolean;
    stringify: (t: T) => string;
    parse: (s: string) => T;
  }
})

я удалил свой пост, когда вспомнил, что мы приводим не к строке, а к plain json

желательно, чтобы апи делал неконсистентные состояния невозможными:

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

функция для десериализации всегда идёт в паре с сериализатором (обратных кейсов я не нашёл), то есть не должно быть такого, что сериализация указана, а десериализация — нет

поэтому вопрос скорее в именах самих полей, сам апи вида false | объект с двумя функциями вряд ли получится существенно изменить

правда тс любит ломать типы во вложенных объектах, так что есть небольшой шанс что придётся записывать функции без вложенности, но я надеюсь это не тот случай

мы приводим не к строке, а к plain json
🤔

const $token = createStore<T>('', {
  serialize: false | {
    stringify: (t: T) => string;
    parse: (s: string) => T;
  }
})

О, выглядит как то, что нужно

напрягает что у записи с заглавных букв, toJSON, есть сайд-эффект https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#tojson_behavior

не могу пока оценить, насколько это критично, но получается сходство toJson ✅/ toJSON❌

А если?
serialize: return [serFn, deserFn]