Вот с этого и стоило начинать, это в корне меняет дело.)
Если есть желания использовать энумлайк объекты (и, имхо, они лучше объектов), то лучше их использовать правильно:
Привязывать строго название свойств к значениям не стоит, энумы подразумевают свои правила. Впрочем, это, конечно, не является обязательным. Ключевое тут другое: возможность использовать энум как тип напрямую используя имя энума.
Что-то тут автоматизировать смысла мало (или вы каждую неделю новый энум создаёте?), тем более, что создание типа всё равно особо не автоматизируешь, НО функцию-генератор сделать всё же можно (класс тут вот вообще никаким боком не подходит, откровенно говоря, он просто не предназначен для этого).
часто опечатки делаются при их задании
Но вот этот момент я вообще не понял. Если функция-генератор у тебя уже есть, то откуда опечатки? Если в значениях, то тут в любом случае от них не защититься никак вне зависимости от реализации. А где ещё она может быть — непонятно, ведь ты передаёшь только значения в функцию (во всяком случае должен, если правильная реализация). А массив значений тебе в любом случае вручную составлять.
Так что лучше скинь текущую реализацию сюда (или возьми решение Alexandroppolus выше), поскольку, судя по всему, ты борешься со следствием, а не с причиной.
Искажения в любом случае будут хотя бы по той причине, что одна и та же буква каждый раз сглаживается по разному в зависимости от своего местоположения.
Но близкий результат можно получить банально выкрутив контраст на максимум и поигравшись с яркостью.
Return Me Void, ничего. Ещё раз повторю вопрос: зачем тебе динамические значение в экземпляре класса? Назови хотя бы одну причину, по которой ты не можешь запихнуть их в отдельное свойство класса.
На данный момент, исходя из описания, ты хочешь получить объект, но объект != класс и класс != объект. Инстанс класса — да, по факту объект, но если использовать инстансы класса как объекты, то... Можно, но это как микроскопом гвозди забивать. И из-за этого (имхо) в тс и сделали это ограничение.
И, всё же, утоли моё любопытство, пожалуйста, для чего тебе такой объект (ключ = значение)?
Return Me Void, я не буду спрашивать зачем тебе в целом такой объект, но я не понимаю, зачем тебе класс, в теле которого всякий мусор лежит? Для чего? Ты даже свои свойства и методы в него добавить не сможешь, потому что в любой момент они могут перезаписаться.
Откровенно говоря, всё это выглядит как костыль для костыля. А решение очень простое: просто сделать нормально.
Return Me Void, если я всё правильно помню, то тс в классах только статические свойства допускает. С другой стороны, а зачем в классе вообще динамические свойства? Если так нужны, можно просто отдельное свойство добавить, в котором и будет объект с нужными свойствами.
Есть, конечно, костыльный вариант через статический метод создания инстанса, тогда можно тип подправить, но... Опять же, зачем, ты всё равно к этим свойствам даже обратиться нормально не сможешь.
В целом, какую задачу ты решаешь?
Просто циферка.
Сами по себе года являются лишь фильтром, в первую очередь. И если твои года не соответствуют твоим знаниям, то это минус, а не плюс.
В целом, после интервью, когда ты начинаешь задавать вопросы, последний вопрос может быть "как я справился" и, если разрабы не против, дадут тебе сразу прямой фидбек.
Adamos, аналогично. Причём это поведение, если мы говорим о главной странице, только в разделах "Рекомендуемо для вас" и последнем, где инфинити скролл. А в самой карточке рекомендуемое открывается как при прямом переходе по лкм без создания новой вкладки.
OliveRrRrr, затем, что это усложняет навигацию по файлам. Вот тебе надо открыть конкретный файл, как ты это сделаешь, когда у тебя одни индексы везде? Вручную через юи? Далеко не всегда удобно.
Так же это сильно усложняет навигацию по вкладкам. Когда у тебя на панеле с десяток индексов, удачи по ним переключаться, в том числе с помощью ктрл+таб.
Так что в индексах должен быть ТОЛЬКО реэкспорт и ничего более.
А вот делать отдельную папочку для хуков уже спорное решение. Особенно, когда он у тебя один.
Да и от реэкспортов из сегментов лично я уже отошёл, геморно за всем этим следить ради сомнительного профита, только реэкспорт из слайса оставил.
Вот с этого и стоило начинать, это в корне меняет дело.)
Если есть желания использовать энумлайк объекты (и, имхо, они лучше объектов), то лучше их использовать правильно:
Привязывать строго название свойств к значениям не стоит, энумы подразумевают свои правила. Впрочем, это, конечно, не является обязательным. Ключевое тут другое: возможность использовать энум как тип напрямую используя имя энума.
Что-то тут автоматизировать смысла мало (или вы каждую неделю новый энум создаёте?), тем более, что создание типа всё равно особо не автоматизируешь, НО функцию-генератор сделать всё же можно (класс тут вот вообще никаким боком не подходит, откровенно говоря, он просто не предназначен для этого).
Но вот этот момент я вообще не понял. Если функция-генератор у тебя уже есть, то откуда опечатки? Если в значениях, то тут в любом случае от них не защититься никак вне зависимости от реализации. А где ещё она может быть — непонятно, ведь ты передаёшь только значения в функцию (во всяком случае должен, если правильная реализация). А массив значений тебе в любом случае вручную составлять.
Так что лучше скинь текущую реализацию сюда (или возьми решение Alexandroppolus выше), поскольку, судя по всему, ты борешься со следствием, а не с причиной.