http://frontender.info/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

react все больше осознает свою функциональную природу - https://facebook.github.io/react/blog/2015/09/10/react-v0.14-rc1.html#stateless-function-components

Ух ты, интересно.

альтернативный синтаксис определения функций это пиздец конечно

@prepor: ты про (a, b) => { a } ?

@asolovyov: ага. ребята заигрались как-то...

так а чо?

по-моему норм, убрали слово function и супер

как бы, чего и нужно было

надо еще {} убрать

тоже очевидно лишние же

😃

ну ad absurdum это ок, но целом тебе просто не нравится, что теперь есть два варианта вместо одного?

мне не нравится то что ребята начали изобретать новый язык для какого-то легкого синтаксического сахара

ну он не совсем лëгкий, он же относительно this себя иначе ведëт

ТЕМ БОЛЕЕ!

Количество слов function в javascript-программах зашкаливает.

Так что такое сокращение - это хорошо.

{} тоже

и скобочек еще многовато имха

ага, но пох на жс

кто-нить пользуется каким-то роутингом?

или писать самому надо?

iproute2

👏

я pedestal-овским

(если ты про это таки)

не, я в смысле для clojurescript'а

что-то я совсем забыл контекст выгрузить

я вот на pushy смотрю, а они там предлагают три варианта - secretary, bidi и silk

и мне ни один не нравится

ну значит пиши свой, что ж делать

договорились %)

niquola еще своим роутером хвастался https://github.com/niquola/route-map

а чем secretary не нравится?

секретари самый ужасный

у них макрос на каждый урл

и что я должен делать внутри него делать? я хочу в компоненте диспатчиться по урлу, а не иметь для урла коллбек

в route-map GET/POST, откуда у меня такое, я ж на фронте

@asolovyov: я делал как то так: (defroute offers "/offers" [] (assoc-state [:page] [:offers]))

а в компоненте уже диспатчился по стейту

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

В компоненте диспатчиться по урлу - это пичаль и ахтунг.

@dottedmag: а шо делать?

Как @prepor советует - делать URL частью стейта.

не, ну блин, один хер ваще-то

Не. Так ты развязываешь state и URL, и компоненты у тебя становятся менее привязанными к конкретной структуре урлов.

Как @prepor советует - делать URL частью стейта.

ну один хрен, я могу положить весь урл в стейт

что я и собирался сделать

и по нему уже диспатчиться

вопрос, где я буду процессить урл - перед тем, как положить, или после - нерелевантен

@asolovyov: хорошо, а что будет если урлу схешем открыть в новой вкладке? будет ли у клиента такая урла для перехода?

ну вот секретари можешь пропарсить урл перед тем как положить )

Попарсить может что угодно, это неважно.

bidi + pushy тоже

@a.espolov: а какая разница?

@prepor: мне не нравится этот подход

большая

:))

@a.espolov: типа, если я буду парсить заранее, то что-то лучше будет?

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

каждый раз когда приложение будет загружатся

что?

секретари + goog.History в этом плане закрывают вопрос

блин, чувак

парсить я буду до или после - ваще пох

если сделать плохо - то тоже пох, где парсить

твои консëрны ортогональны проблеме

@asolovyov: поподробней про свое решение расскажешь?

понял

я правильно понял, что ты хочешь прокидывать в стейт компонента урл и соответственно на основе маршрута внутри компонента определять как отрендерить компонент?

в стейт приложения

но да

с одной стороны стремно, когда компонетов дохера и маршрутов то же

с другой будет работать и придумывать ни чего не надо

так серьëзно, а какая разница? Функция-диспатчилка будет либо до, либо после, но разницы реально никакой

@asolovyov: я пользую bidi, он наименее ужасный из всех

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

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

хм, ок, гляну на него внимательнее всë-таки

я когда-то пытался его на сервере заюзать, и потом запутался в роутах :))

а в каком смысле запутался?

может я сталкивался и у меня есть костыль)

ну я тоже всегда путаюсь в биди, какой то шизанутый там “синтаксис” ) но есть формальное описание, это спасает )

как решите, какая лучше всех, мне тоже расскажите :) а то я по неопытности взял secretary и немножко с ней страдаю

о кстати

или некстати

а как вы делаете пагинацию?

по идее, проще всего сделать кнопку 'moar' и каждый раз подгружать новые записи больше последнего встреченного id, например

так и есть

но я не делаю пагинацию, поэтому мне хорошо

@rm: почему проще?

там же все равно тоже самое будет

@asolovyov: как так?

суть пагинатора работать с набором данных который соответствует текущему стейту(например), а как он будет отрисован как разница?

@rm: ну ото такие требования

@a.espolov: ну не будешь ты на клиент 5000000 записей совать, например.

@a.espolov: проще чем что?

@rm: ну я в принципе буду пихать шо скажут, но сейчас у меня вообще ужас нереальный, а буду заполнять по мере скролла, наверное

@asolovyov: там чуть выше

@rm: https://modnakasta.ua/campaign/s-8194-keddo-betsy-elisabeth/f/all/ - зацени вот, никакой паджинации, бизнес хотит

воу

@a.espolov: не вижу альтернатив описанных, ггг

@rm я сделал так же, когда увидел первый раз 😃

оно еще и тормозит, джанга рендерит этот ужас 500-700 мс %)

@asolovyov: infinityscroll не пробовал прикрутить?

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

@a.espolov: ну в текущем варианте бекенда прям очень неудобно это будет делать

но так и будет, канеш, просто руки не дошли еще

знаешь, типа, пока работает - и ок, другие-то части иногда не работают

знакомо

до боли

ничо, мы прям на след неделе уже этим начинаем заниматься

не прошло и полгода! %))

хехе, моя история

(прошло на самом деле, но всë остальное важнее было, ггг)

@asolovyov: кстати хорошая идея избавиться от method - я как раз начал его в cljs использовать - зарефакторю - опционально поместив его в конец пути последним элементом

https://github.com/niquola/route-map#clojurescript