привет. А как мне в cljs сделать свап в двух местах или последовательно, или так, чтобы реакт не влез между двумя свапами?

ну или можно как-нибудь типа (swap! x assoc :x 1 assoc-in [:y :z] 2) ?

транзакция то есть нужна? ref и dosync в клжс можно кстати?

да, транзакция

нет

1 же атом

у меня в другом проекте есть решение с core.async, но это как-то стремно тащить его ради пары строк.

(swap! x (fn [value] do anything here ))

о

спасибо

блин, как же я так. fxposter, большое спасибо

(swap! x (fn [x] (do (assoc x :x 1) (assoc-in x [:y :z] 2))))

так не сработает же

(swap! x (fn [x] (-> x (assoc :x 1) (assoc-in [:y :z] 2))))

так сработает

а чому не сработает? В репле вроде ок

аа

понял

еще раз спасибо

не за что

а как в datascript задать первичный ключ?

@rm а ты datascript в связке с чем используешь?

abtv: с реагентом. Или что ты имеешь в виду? База на сервере? мускул

Пацаны, кто-нибудь занимался локализацией приложение в clojure / clojurescript?

@rm да, именно фреймворк на фронте. ты и datascript базу используешь и в атомах данные хранишь?

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

а почему все в датаскриптовой базе не хранить, тормозить будет?

а зачем все? там все, что не в датаскрипте -- единичные значения

ну один способ доступа чтобы был, хотя и правда, наверное, не факт что нужно, если там разные сервисы

чота все равно не понимаю. Вот у меня есть игрушечное приложение, в нем такой стейт:

(defonce default-state
  {:date nil
   :requested? {:users false :meals false}
   :meals (db/empty-db {:meal_id {:db/index true}
                           :date {:db/index true}
                           :time {:db/index true}})
   :users {db/empty-db {:login {:db/index true}}}
   :user "one"
   :filter {:date {:from nil :to nil}
            :time {:from nil :to nil}}})

@prepor я ковырял локализацию, а что интересует?

@delaguardo: для начала решение работающее и в clojure и clojurescript одновременно

@delaguardo: с каким-то простым форматом определения строк, который можно свести к стандартным key/value (gettext, json)

@rm я так понимаю, что у тебя часть данных в базе на клиенте, а часть в атоме, правильно?

tower неплох если только локализация, без плюрализации и форматирования дат и чего нибудь еще

https://github.com/DeLaGuardo/boot-gettext - вот еще моя поделка, сырая правда сильно

abtv: ну вот стейт он один, суется в атом и потом туда складываются и базы, и значения.

delaguardo: tower по первых не сводится к k/v. во-вторых плюрализация нужна конечно )

delaguardo: оно mo файлики генерит или таки с gettext его ничто не связывает?

и оно генерит какой-то свой формат?

ничего кроме названия не сыязывает (

не довел пока до ума

@rm вот тут я запутался) я с датаскриптом не работал (потому и спросил), но а как ты данные запрашиваешь и изменяешь? у тебя есть сервисный ns для этого, который уже содержит детали реализации (swap! для атома и что там есть для датаскрипта)?

abtv: ну потому что датаскрипт -- это не совсем база, это такой хитровыдуманный мап

http://codepad.org/6oYJT12d вот мой ns для стейта, обрати внимание на update-meals-state

а зачем ты делаешь (:meals @state) если он у тебя уже в x? @rm

в смысле: зачем @state?

и правда

и можно (fn [{:keys [meals] :as x}] ... ) чтобы лучше читалось

меня чего-то смущает хранение базы внутри атома вместе с другими значениями... может я чего-то не понимаю @rm

если это чисто мап такой, то ок, но как-то странно

ну получается удобно

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

нет

я ее обновляю

то есть, если есть в ней 100 записей, а прилетело еще 100, то я напишу (db-with old new-map) и оно обновится

а блин

да, я ее заменяю :)

ну дык ФП, вся фигня

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

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

можно, там есть функция transact!, но я не осилил им пользоваться

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

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

а как реагенту бибикать, что оно обновилось и пора перерисовать?

@rm: ну стейт обновить.

@rm посмотри здесь https://gist.github.com/allgress/11348685

potapenko: ну для этого датаскриптовая база должна быть в стейте. Я не вижу в этом ничего плохого, но abtv протестует

основа реагента их атомы и реакшены

я вижу, ты тут используешь create-conn. Я так понимаю, там обычный, нереактивный атом

сделай фейковый атом и обновляй его

без атомов делать как-то через задницу

ну мне сложно сказать, я датаскрипт не юзал, но я думаю, что (ds/db-with (:users @state) data) не изменяет данные в базе как задумано разработчиком датаскрипта, а создает новую базу, вот тут я и протестую, как говорит @rm потому что коряво. А в связке реагента и датаскрипта судя по примеру (не моему) будет возня с подписками и отписками в :component-will-mount и :component-will-unmount , чтобы сказать реагенту, что данные изменились и пора перерисоваться. В общем, я не настаиваю, потому что сам не знаю, но мое чутье протестует

презентация в тему http://www.slideshare.net/fractallambda/datascript-and-reagent

@rm ^

abtv: спасибки, потом гляну

в двух словах, как они делают?

напомните плиз, а чому реагент, а не ом?

ом сложный

он притворяется

хотя я не долго его пинал, может чо не понял)

@rm а ничего нового: создают атом и используют datascript/listen!, который сам изменяет значение атома, когда меняется значение по конкретному запросу. Просто ты внутри каждого компонента вызываешь bind (в котором спрятан вызов datascript/listen!) и он уже возвращает тебе обычный атом для реагента. В презентации почему-то нет примера с вызовом unbind, думаю его нужно вызывать, чтобы не плодить лишние атомы.

ну и bind сам может создать атом, если ты ему передашь соединение и запрос.