This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-05
Channels
- # beginners (23)
- # boot (84)
- # braid-chat (2)
- # bristol-clojurians (1)
- # cider (53)
- # cljs-dev (34)
- # cljsrn (13)
- # clojure (138)
- # clojure-dusseldorf (5)
- # clojure-italy (1)
- # clojure-russia (164)
- # clojure-uk (41)
- # clojurescript (80)
- # clr (2)
- # core-async (6)
- # core-logic (25)
- # core-matrix (14)
- # cursive (10)
- # data-science (4)
- # datomic (4)
- # emacs (3)
- # funcool (6)
- # hoplon (127)
- # jobs-discuss (4)
- # keechma (36)
- # ldnclj (5)
- # lein-figwheel (5)
- # off-topic (5)
- # om (155)
- # onyx (72)
- # overtone (16)
- # parinfer (39)
- # planck (3)
- # protorepl (1)
- # re-frame (11)
- # reagent (5)
- # untangled (22)
вот какой ад показывает lsof -> http://take.ms/Qiely
видимо клиент некорректно закрывает tcp соединение и моя функция не может обработать его
в manifold есть функция connect позволяющая забиндить обьект stream на chan. и далее работать уже с каналом
по-моему @asolovyov и @prepor уже что-то похожее с каналами обсуждали
да тут не с каналами проблема. напрямую опрашиваю все подключения на manifold.stream/closed? и он мне говорит что все открыто
понятно дело что баг в клиенте. но я не могу на него повлиять ) ибо это железка стороннего производителя
есть у меня id этой железки. буду проверять в существуюющих подключениях, и прибивать не актуальные
@andre: я планирую
кто-нить Rum уже использует? Как оно ащще?
@artemyarulin: @asolovyov вроде как
ага, вижу что он контрибьютил туда аж - чо готово оно к продакшену? Меня просто чота ом-некст поддостал, либо я мож тупой канеш, но оч тяжело идет
ага, это и радует
а как там c RN поддержкой? В cljsrn канале грили что вроде все пучком и на хелло ворлде работает
а точно, он. @misha Как там? Мож есть где gist чего поменять надо? Хочу поиграться
Про Rum - т.е. апи стабилизировалось, менять по крупному ничо не будете, можно брать?
отлично, поиграюсь
@andre: @ssesutchenkov тоже думаю заглянуть
@artemyarulin: берешь любую версию, и перед тем, как будешь маунтить рутовый компонент, пишешь:
;; где-то у тебя уже будет это:
(set! js/window.React (js/require "react-native"))
...
(defn mount [component node]
(js/React.render component node))
ааа, точно же - функция же. А пример из ридми будет работать?
(let [component (rum/mount element dom-node)]
(add-watch state :render
(fn [_ _ _ _]
(rum/request-render component))))
как мне перерендерить если стейт поменялся? будет render queue работать?
ну и с чем колупаюсь сейчас, так это знать что и когда оборавичивать в js->clj
, при работе с нативными (jsx) компонентами, типа фейсбучного Navigator
пример какой именно?
у тебя в компонентах будут не [:div ...]
, а (touchable-highlight ...)
как ты ререндеришь когда стейт поменялся? вызываешь еще раз mount?
я еще вебапп недопортировал так, что бы можно было сказать "работает"; но думаю за сегодня-завтра прикручу
(rum/defc nav []
(navigator
{:initialRoute (routes/home-page 0)
:renderScene dispatcher
:configureScene animator}))
(defn mount [component node]
(js/React.render component node))
(def root (nav))
(defn init []
(mount root 1)
(.registerComponent app-registry "rumapp" (fn [] root)))
а потом нажал кнопку - пушнул роут навигатору, он на нем вызвал диспатчер, который отрендерил вью новую
а т.е. у тебя нет глобал стейта как в оме, понял ага
либо делаешь атом, маунтишь глупую вьюху, которая rum/reactive
на этот атом,
а внутри по клику меняешь атом, и вьюха сама ререндерится, потому что там типа watcher на атом реагирует
а ну вот - я спрашивал про это, работает - круто
ты смотри - датаскрипт народ грит медленный на мобайле - в cljsrn народ жаловался и уходил с него
а вот с этими танцами с app-registry я не разбирался особо, пока что у меня 50/50 карго-культ/копипаст дривен девелопмент
ну на лаптопе он достаточно шустрый. по крайней мере восстанавливать дохера данных из локалстораджа
app-registry я знаю, разбирался когда свой враппре писал для RN https://github.com/artemyarulin/ktoa/blob/master/src/ktoa/core.cljs#L32-L43
ну я за что купил - за то продал) Ты спроси на #C0E1SN0NM
может где-то кешировать чо получится. на вебе я вычитывал 1 раз "всё" дерево данных в рутовой вью, и спускал как аргументы чувакам ниже. а по ивентам - писал в ДС, получалость ваще ок, особенно, если в дебаунс обернуть. подозреваю, что если в каждую вью передавать айди сущности, и каждая на рендер будет в ДС ломиться за данными по этой айди - могут ласты склеиваться начать, да
не планируешь какой пример в опен сорс выпустить про rum + RN + DS?
я бы посмотрел
это в ом DS хз как вкручивать, и там расцвели туториалы. а тут всё просто. сложно react-native->cljs
@artemyarulin: а ты на обычный Om, он же Om.old смотрел? Тоже сложный?
@abtv: ну он вообще неинтересный, много текста, а толку не больше, чем со всего остального
хм, у меня он тяжело идет, да, но я это пока списываю на неумение готовить. те же запросы + если с датомиком то будет круто, без реста и т.п. @asolovyov
Я вижу плюс в том, что он должен меньше данных гонять и в том, что в компоненте можно декларативно объявить все данные, которые ему нужны. Или я вообще не туда?
Ну во первых хотелось попробовать натянуть om на уже имеющийся api. А во вторых не вижу больших преимуществ от предложенного omом варианта общения с сервером(на серве тажа каша из end-points, только rest для меня понятней).
@lapooh: а что привлекает в om.next кроме предложенного механизма взаимодействия с сервером? мне казалось это основная его фича, нет?
Один атом, декларативное описание данных для каждого компонента на основе запросов, нормализация стейта и даже механизм синхронизации(хотя пока не понятно как его кастомизировать)
а где есть нормализация кроме датаскрипта? @rmuslimov
когда, мы имея минимальный набор данных можем развернуть его какой-то fn которая будет меняться с начальным представлением
@rmuslimov: ага, я тоже не видел это
у тебя граф или дерево? тут вся разница (ну да, там тоже может быть по разному, но в общем) @rmuslimov
ничего подробного не могу найти https://github.com/Day8/re-frame/wiki/Writing-Subscriptions
Ну идея понятна, но это всеже ручной привод, в то время как в om.next это обеспечивается из коробки
@lapooh, если бы ом-некст налез мне на голову за пару недель, что я на него потратил - я бы наверное на нем писал бы сейчас нативную приложуху: там подкупает решенное за тебя "брать из локальных данных или с сервера"и всякие декларативные описания "что какой вьюхе нужно, и тд." но не налез
хотя провозившись с ванильными доками, бложеками и туториалами для реакт-нейтива - сильно яснее стало, так что если вдруг с ромом в тупик жосткий зайду, может на нексте переписать прийдется
@abtv: Оригинальный ом не смотрел. Я ом некст пытался сделать как основной либой для 1 текущего иОС приложения + одного будущего + веб сайтик с целью пошарить как можно больше логики. Казалось бы декларативные запрос у компонентов, но: - Сами авторы говорят: reusable component - pure component. Запросы мимо кассы - Апи у меня рест/soap(sic!) и нативное IO операционной системы - опять мимо Ради одной нормализации - это перебор. Ну и да - толи я может сильно тупой, толи доков не много - но я ом-некст месяца 3 копал и все еще дофега не понимаю
тот же Rum я нашел сегодня и за часик понял что да как
ах да - я еще пытался просто бложек на ом-некст сделать, как из пушки по воробьям чтоб сделать remote fetch недостающих данных, ди и то и неосилил чтоб прям красиво было и все понятно для себя.
ну я тренировался Т.е. я думаю если датомик на беке - то вопросов вообще не должно быть, в остальных случаях - сильно хз
я думаю, что если у некста есть преимущества, то они только для сурьезных приложений, там где куча всего (запросы, локал/ремоут), нужна производительность (сильно близко к RN: там js прямо из каждой строки на тебя смотрит), и что-то еще. но что бы доказать превосходство, сначала нужен огромный апп, а потом его еще и написать на оме/роме, и сравнить
я написал за пару страниц синхронизацию датомика с датаскриптом. правда она зависит маленько от самих данных (нужно знать, какой сабсет данных тебе нужно синхронизировать, чтобы тащить только контент конкретного юзера). и что-то не вижу как в оме было бы проще
ну вот про большое приложения я наверно соглашусь, вот про производительность нет - Rum/Reagent/Rum, все они с RN работают 1 в 1, разницы не должно быть
ну вобщем да. Я как “ниосилятор” больше не буду гнать на ом - буду рад если тут чуваки поделятся положительным опытом
вооот)
ну для справедливости - оно ж альфа еще, доков/примеров нет/мало
какой там хайп будет когда ом зарелизят, уу
https://github.com/r0man/sablono/wiki/Optimization-Tips - вот эту штуку кстати нужно знать однозначно
> You can explicitly set the attributes to {} and avoid the ambiguity of children vs attributes that would need to be resolved during runtime.
у меня без пустого {}
реакт-нейтив и не компилится
cljs.user=> (def u {:db/id 1 :user/name "<noname>", :user/stuff [{:db/id 2}]})
cljs.user=> (-> u clj->js (js->clj :keywordize-keys true))
{:id 1, :name "<noname>", :stuff [{:id 2}]}
кстати, про js->clj
. как с ней сделать из жс объекта мапу с кейвордами в ключах вместо строк? я ей что не передаю - все строки там