Regarding deploying webapps where apache2 is the front end to the Internet. Once a webapp server process is up and running there's an extra step that a file in /etc/apache2/sites-enabled needs to be altered to do the final routing to the outside world. For Scala.js and Sente server processes the following approach has worked fine:

ProxyPass /app-name 
 ProxyPassReverse /app-name 

@cjmurphy: It looks like you can supply a different networking object to the untangled client which allows you to specify the server endpoint it talks to: https://github.com/untangled-web/untangled-client/blob/master/src/untangled/client/core.cljs#L20

On the untangled-server side, it looks like the route is hard-coded in the handler, though there may be a way to fake it with supplying extra routes. Or fork untangled-server. Or just use the Om Next library directly in your own backend.

@cjmurphy: You could use mod_rewrite. You're generally correct that we could provide more customization of the URL supported by the webapp itself. You could do as @grzm suggests. Not difficult, either. I'd be glad to entertain a PR on untangled-server to configure the API endpoint via the configuration file. It is a relatively simple change, since the config is injected. My basic approach at the moment would be to suggest offloading this as an operation concern (e.g. mod_rewrite).

ah, but you'd need at least virtual hosting. In other words route to the apps by vhost name instead of path in URL

I'm updating initial state, passing in a current-user id in a method similar to that laid out by the open-id client (https://github.com/untangled-web/untangled-client/blob/master/src/untangled/openid_client.cljs)

I then get a warning when I also add an initial state to my root element. Is there a better way for me to get the current-user id into the app state?

I guess I could just take the all the initial app state that I would put in the initial element and also inject that at the same time I'm adding the current-user, though that seems kinda hacky.

@tony.kay: any reason you use clz instead of this when referring to the component in initial-state function definitions?

@grzm to stress the fact that it is created initially, which means you're passing in the component class, not a component instance (from a factory).

@tony.kay: What's the mnemonic? Class?

ah, yes...class

I'm allergic to using the word class, since it is reserved in so many languages 😉

Understood 🙂

It's a departure from the use of this for all of the the other static functions like IQuery/query, which confused me at first.

@jasonjckn: not sure why that would be.

@grzm My thinking was that ident, for example, is used with component instances...e.g. with data plugged in.

it's interesting how it does it just for the first key in the vector

@grzm you need that extra arg because it is a protocol, but since it is "static", it is a little odd with respect to the OOP ideas.

you could be passing the class as the "instance", or an actual instance

@jasonjckn: It was a pretty simple change, so I'm not sure why it would not work right. Feel free to submit an issue. I've been crazy busy, so if you see the problem feel free to send a PR

gotcha

k

yeah, ident is a little strange

yah I tried to see if it was a quick fix, but on first inspection the source code looked right

i'll maybe take another look

not a huge deal eitherway

perhaps your diff alg is off?

Remember that the global marker (at the root) is still set

@jasonjckn: I'm not familiar with your app or output...

my diff algo is your diff algo from untangled-spec

i think the marker is definitely there

ah...well, isn't it just showing the global marker?

what's the global marker? ui/loading-data?

yes

yah that show sup in the diff algo too, but i don't care about that, I care about how :env-vars is getting a marker

marker false means you don't want loading markers placed where the data is targeted

The global marker is for showing a global "loading/network" indicator

the latter is always updated

e.g. load-field would put a loading marker on some deep spot in your app state

there's the marker that shows up, even with :marker false

ah, I see

here's the code

(df/load-data reconciler [:env-vars :login-profile :entitlements] :marker false)

yeah, that does look like a marker inside of your data

as I said it only shows up for :env-vars interestingly

the other keys are loaded without markers

Yeah, submit an issue on it. I think the code may be only touching the first thing queried...which might be a separate issue.

I don't remember...I assume you've checked that :marker is the correct option name 🙂

i'll create an issue, yah I checked that

https://github.com/untangled-web/untangled-client/issues/24