no cellophane....just Om Next v alpha45+

@sova

and untangled client v 0.6.2-SNAPSHOT

then yes, a cljc file.

The #js thing requires data-readers, which is in Om next. I've seen it have problems with that...might ask on the Om channel. Really all you need is a data_readers.clj file that has the line {js clojure.core/identity} I think

anything with a # in front of it is an EDN tag meant to trigger a reader. Setting the js reader to identity on clj will do it

but Om should have already done that...might try a clean and restart of everything, and make sure latest version of Om/cljs

At one point I just changed #js to (clj->js { ... }) and put a #?(:clj (def clj->js identity)) at the top of the file

but again, you can do that via data readers

Okay, Thanks a lot @tony.kay I am wondering... how can I know the latest versions available for cljs and also om.next?

@sova I use this https://github.com/xsc/lein-ancient

@adambros Why thank you sir, that is excellent.

(dom/render-to-str) does not appear to exist in om alpha 45, but 46 is good. just fyi

or maybe I spoke too soon.. hrm.

`#object[ReferenceError ReferenceError: ReactDOMServer is not defined] ReferenceError: ReactDOMServer is not defined`... Will snoop. any thoughts in the interim?

Anyone here familiar with this error? Uncaught Error: Assert failed: (or (component? x) (reconciler? x))

@njj it's quite common when i'm doing something wrong.

Look at the stacktrace, it should tell you where the problem is.

@sova I'm using alpha47...perhaps it is fixed in later versions

@njj just means you passed something that was neither a component or reconciler to something (like transact!) that wanted a component or reconciler

(defroute foo-routes "/foo/:bar" [bar]
  (transact! @reconciler [(app/choose-tab {:tab :search})
                          (search/new-query {:status bar})
                              :ui/root]))

my guess is you don't have what you think you have...perhaps that is an untangled app instead?

in which case (:reconciler @app)

(js/console.log @reconciler)

perhaps the issue is: (def reconciler (atom nil))

possibly 😉

this app was setup by a peer of mine who abstracted quite a bit, so unfortunately the documentation isn’t 1 to 1 w/ what i’m looking at

yeah, and your peer is still wrong in not quoting the transact data

Im gonna switch to om/transact versus his transact abstraction

@tony.kay I was able to get things working based off your todomvc example

@njj great

@tony.kay When using the quoted transaction vector, how do I parse params passed in from defroute?

it appears that is turning that param into a string, i.e. “bar” versus whatever param is passed in the actual url

read up on syntax quoting. In short:

(om/transact! r `[(app/f {:p ~arg})])

a backquote is a syntax quote...makes things literal. ~ is unquote

unquote lets just the thing that follow it come from the env outside of the quoted thing

(defroute foo-routes "/foo/:bar" [bar]
  (om/transact! @reconciler `[(app/choose-tab {:tab :search})
                             (search/new-query {:status ~bar})
                            :ui/root]))

something like this?

yep

sweet

single-quote is literal literal

I’m a JS dev, learning CLJS this is my first project w/ it

somethings like that were hidden from me, I guess to prevent having to explain it 🙂

cool. Clojure for the Brave and True is a good online resource

quoting is leveraged mainly in macros

thanks again @tony.kay - really loving untangled

welcome. Glad you like it.

@tony.kay have any examples that don’t use hash routing and doesn’t case a full page reload?

I feel like thats what this is for.. https://github.com/venantius/accountant

I do not. Not really a concern of the framework itself. More about how you want to set up your app.

From my perspective, I really think "back" and "forward" should be no-ops in SPA. If you're writing an application on the desktop you don't have a "back button". Why should we have one just because it runs in a browser? Makes software a lot more complicated. We spend countless hours worrying over it, doing it poorly (because it is basically not cleanly solvable), and not adding the actual useful features users really need. Who is going to not use your product because back is a no-op, but your real features rock? Has anyone honestly stopped using a webapp because back didn't "undo" their prior operation? Does "back" in gmail compose/send unsend your message?

If you're browsing stateless documentation, sure...if you just pressed a button that executed a transaction on the server? WTF?

what is back gonna do?

I think we're doing ourselves a disservice by trying to map stateless doc browsing onto an application

I lean towards disabling back/forward, and just warn that page reloads are not what you want when you try them

Direct navigation to some part of the app seems OK, but the use is rather limited. I can see the benefit of being able to target part of an app from, say, an email link.

stepping off soap box now 😉

catching up here 😄

@tony.kay how about no back button, but clicking a link like /foo/bar doesn’t require a full page reload?

or is that sort of the same..

why do you need the URL to change? Why does it need to be a link at all?

it's an SPA

make the button change the state, which changes the view

bookmarking mostly

no linking involved...it ISN'T documentation

can you bookmark Excel?

its an internal tool, people want to be able to share links

it's trying to map a stateless doc concept onto an application

I understand. I know people write up requirements that way.

Yes, you can do it

I thought you already had that part, though

you should not be seeing full page reloads from, say, todomvc

the item filtering is done via URL

but todomvc uses hashroutes no?

OH. I see.

Yeah, you have to configure the browser to do that

again, not part of the framework itself, just standard HTML5 routing setup

ya its basically like “#/foo” works in my current setup, but we want just “/foo” type thing

cool I’ll look into it, I’ve seen it done in Angular, React, etc.. I believe

https://google.github.io/closure-library/api/goog.history.Html5History.html

the google closure library is automatically available

accountant hacks in that way, I think

The one thing you'd have to fix though, is that you have to get the server to serve your index page independent of what URL it is asked for

cause otherwise if someone starts with that link, then the server will say page not found

cool, so it should just be able to be done by setting it up w/ html5history correctly and telling secretary not to use hash routes

and making sure the server will server index.html when asked for any URI

gotcha

(except /api, which is your untangled API channel)

We use pushy combined with bidi for URL routing. We need it for sharable/bookmarkable dashboards. I think it's an overreach to say SPAs in general don't need routing, but yeah, for the most part we only route the stuff that might be bookmarkable, not every single action.

@therabidbanana does your setup use secretary at all?

No - I think bidi takes the place of that

ok interesting.. thanks

I definitely need shareable/bookmark-able for the same reason as you

Thanks @therabidbanana . I agree that some things like that are needed. Like I said, more of a soap box sore spot 🙂

Basically you hook up pushy to call a function on every route change, in our case it's basically just a direct call to om/transact! - but we have it tack on other actions besides (route/update) based on url (for example, some data we don't pull until you jump into a specific dashboard, so if you hit a dashboard route we can tack on an (untangled/load) in the transaction

@therabidbanana have an example you can share of the direct call on transact? I suspect my setup would be similar

So the key bit of code is in the update-fn we call in mount. mount is called with the reconciler during app initialization.

Handlers is the bit with the extra info to tack on to route transitions for untangled lazy loads.

:thumbsup:

Looks like pushy takes two functions when you initialize it - one for what to do on a match - update-fn, and one to transform url to match parameters that get passed into the update-fn, which we call url->route

To be fair to @tony.kay though - we needed routing as much to prove untangled could stand up to Ember.js as we did for actual usage of the feature. In general we probably have more routes than we need. 🙂

@therabidbanana I was able to drop pushy in my project w/ existing code around secretary and have no hash routes 😄

Sweet

btw @tony.kay I forgot to mention, the project I’m working is with jason jackson

he said you might know him

@therabidbanana ah yes...must have routes in Ember, else we might forget where to pee

Pretty much yeah

@njj sure! we've interacted a decent amount

haha re: Ember

it was like their #1 thing in that first instructional video

YOU MUST HAVE ROUTES, OTHERWISE CHAOS

there's now 3 engineers and 1 project manager on our untangled app 🙂

Nice Jason

we're spinning up a staff of about 20

Well, to be fair to Ember, the router is Ember's version of the reconciler - a single source of truth in charge of the hard getting/synchronizing data stuff. The fact that it's tied to urls is more of a byproduct of just trying to have some reliable abstraction like that.