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 <http://0.0.0.0:8082/app-name>
ProxyPassReverse /app-name <http://0.0.0.0:8082/app-name>
However this approach doesn't work with Untangled. I can deploy one Untangled webapp. But I can't seem to be able to deploy more than one. I always get stuck at the point where messages to the Chrome dev console say that /api
can't be found. I don't want /api
to be looked for, but rather /app-name/api
.@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