Just published a new tutorial video (part of a series I'm working on): Untangled/Om Next In The Large.
Part 1 covers the very common and popular problem of structuring your app (Union queries, including nesting them), and HTML5 routing (with params)
Source code and helper macros included and linked from the video description
awesome, thank you 🙂
Hi guys! I'm interested in an overview on untangled, but on the website I can only find detailed guides a videos
@doddenino I found these videos really helpfull for a general overview: https://www.youtube.com/playlist?list=PLVi9lDx-4C_Qsgm8JC1VyMevV9DVj-dCh
@doddenino Here you can find the documentation for Untangled: http://untangled-web.github.io/untangled/docs.html. The Developer's guide was really helpful for a quick overview for me, especially the Quick tour.
Thanks guys 🙂 I will check the videos
@tony.kay what's the difference between your routing approach and just the 3 line secretary + html5 routing approach ?
Hey Jason
um, remind me
my approach is about tying the html5 routing to an arbitrarily large set of unions in Om
in a structured way you can easily extend
next video coming later today
@tony.kay in our app, we make links <a href=/foobar>
when the user clicks that link secretary dispatches our route handler which in turn calls transact!
right, no difference there, and I think mine is 2-3 lines for that part
the rest of it is about large applications
ok gotcha
the fact that you want your queries to end up small, which means lots of union queries...which in turn are finiky
so, a macro or two and some invented functions the help make the overall structure/union switching declarative
such-and-such a route switches this set of well-known union (routers) to the correct spot
ok, i'll take a deeper look at your solution, our app is structured like your TabUnion recipe
yep, like that, but bigger
one giant Root agg TabUnion agg everything else
thus "In The Large" 🙂
kk
oh. I see
yes, you can do it that way
Is that composing well for you? Don't you have sub-screens that come in and out of view...or did you flatten everything?
everything is flattened
for better or for worse
Ah. That seems less ideal for a large app in terms of composition
yes perhaps i'm glad you fixed that nested Union bug, it's definitely nice to have this option on the table
yeah, sorry about that...did that bite you?
perhaps that is why you felt you needed to leave it flat
😕
I don't think we hit the bug yet, I haven't trained the others on the team in Unions yet which is probably why lol
but had the known they probably would have used it as our app is growing quite complex
well, the macro makes it much nicer. Check out the video and source
kk
we use the same approach: a macro which generates one big flatten union query - router component (like the tabunion example)
yes we also generate the union query
the big flat is fine for a lot of cases...I was assuming though that people might have complicated screens that needed to compose in sub-screens..e.g. which include part of the parent
which indicates a tree
kk
side-by-side things that can change independently, etc
complex applications is why we picked untangled so happy to see solutions like this even if i don't need them yet
for sure
sorta like the chat section in gmail, overlays, etc
one of our apps got really laggy because complex nested screens were not using unions
@tony.kay - which topics are u covering in the next video?
had not decided 🙂 I've got code written to show component development and screen development. I'll probably start with component
since I have more to show there
at least so far 🙂
the usage of devcards -> workflow during development?
yes, but with some specific tips and workflow hints
rather: yes
I have an HTML->React converter too
makes pulling things like bootstrap examples a copy/paste exercise
awesome…sounds like a very promising and helpful ressource for beginners like me
I couldn’t find any good ressource how devcards could speedup my development workflow
I'm wanting to include @therabidbanana tips from this blog post https://medium.com/adstage-engineering/how-we-test-our-full-stack-clojure-app-b18d79ee9e00#.3v0ps49ty in somehow as well. I'll probably just refer people to his post in the description and verbally. His idea on using devcards for automated UI testing is cool
it's just visual regression testing, but it's a great combo of devcards and the general idea
nice