подскажите, как можно деструктурировать часть аргументов функции в переменные, а остальное в общую переменную? то есть, в выражении ниже мне не нужно что бы в переменной props
были ключи class
, type
, size
, icon
(defn render
[{:keys [class
type
size
icon]}
:as props}
...
все что я могу прибумать - это внутри функции сделать
(let [props (dissoc props :class :type :size :icon)]
...)
но это плохо, мне приходится дважды делать перечисление одного и того жемне кажется нельзя так сделать
прям жаль. это довольно частый кейс. агалог в js
const render = ({
class,
type,
size,
icon,
...props
}) => (
...
);
наверное нужно какой-то макрос в таком случае написать
Я думаю в такой конструкции мало пользы. Обычно из мапы выбираешь только нужные тебе свойства. Поэтому вполне нормально выбрать деструктуризацией то, что нужно и передать мапу дальше, и там там тоже выбирать необходимые значения и т.д. по цепочке
@roman01la у меня это очень частый кейс. Например, я делаю компонент [forms/input]
у которого есть свойство icon
, которое рисует иконку внутри инпута. так вот я не хочу перечислять все свойства которые могут зайти в нативный input (`on-change`, on-mouse-click
, auto-focus
и много других), я просто хочу сделать, например, следующее (это псевдокод):
(defn input [{:keys [icon]
:rest props}]
[:div
[:img {:src icon}]
[:input props]])
я понимаю, что я могу сделать :as props
, но тогда в моем отрендеренном компоненте у инпута будет атрибут icon
, который я там видеть не хочу. Этот кейс очень частый для всех элементов форм, напримерМожет быть. Но всегда рекомендуют, и я так делаю, явно пописывать поля для эелементов. Что бы не было таких казусов. В JS то же самое
Потом проще понять что туда приходит, не нужно дебажить
это утверждение верно для компонентов более высокого уровня
Наоборот это как раз для DOM элементов
Вроде бы в доках реакта об этом есть немного
ну если я создаю копнонент <Button />
люди которые будут его использовать подразумевают что он умеет все что и умеен нативный button
, а мне просто приходится зайти в спецификацию button и перечислить все атрибуты которые у него есть, что бы ничего не пропустить. я в этом смысла не вижу
для кастомных копонентов приложения я согласен, так лучше не делать
Это стандартная проблема explicit vs implicit :) Кому что
🙂
напиши макрос
или FR в destructure протокол
Функцию напиши, которая 1 мапу на 2 делит
А вообще добавить в clojure.core/destructuring :rest или & было бы удобненько
я о том же
польза будет какая для общества
Там 1 функция плотная на 90 строк, расширить можно только переписав, на сколько я вижу
можно только кейс для pmap переделать
40 строк, уже легче )
так не нам же переделывать, а @y.khmelevskii
Только рич скажет - деструктуризация - сильно хот, нечего туда ваши рога совать с выдуманными юзкейсами
я ж и говорю, FR сделать и посмотреть что будет.
Что такое FR
feature request
а
Но упражнение интересное
ну пока сделаю для себя макрос, и напишу в чатик #clojurescript. Там Нолен вроде очень активный, может прокомментирует
FR я не осилю пока )))