Fork me on GitHub
#fulcro
<
2019-09-09
>
cjmurphy00:09:55

Thanks Tony. I'm attached to looking at the type of the id in Fulcro Inspect, so just happy that (tempid/tempid) and (random-uuid) look different there.

jimrthy02:09:05

I've started from the fulcro3 template and am converting the server to use pedestal, immutant, and reitit. The way things are now (which is almost all just trying to tweak default examples to get the stack working), trying to handle the /api POST request causes a 500 error on the server. That's returning JSON: {"type": "exception", "class": "clojure.lang.ExceptionInfo"} That leads to Call to #'com.fulcrologic.fulcro.ui-state-machines/handle-load-error* did not conform to spec. followed by Uncaught SyntaxError: Invalid regular expression: /[\\" ]/: Stack overflow on the browser. I must have seen a doc that describes the request, because I basically know what I'm looking for. But I don't think I've seen anything (before this spec failure) that describes the error response I should be returning. Is that document something that would be worth adding somewhere? Would it be worth catching this sort of problem in fulcro and supplying a specific error message? I vaguely recall something about avoiding most error handling, since we expect most fulcro developers to control both sides of the connection, so this doesn't seem like an obvious win. But it does seem worth mentioning.

tony.kay03:09:09

So, that’s a mess of mess…The template does some session based resumption logic that asks the server if it recognizes the user. Not sure what the spec was looking for that didn’t match. So, a 500 causing spec failures in UISM is a bug. As far as the request/response goes: just look at the template and fulcro source. There is very little to it. It is a POST API supporting EQL over transit.

tony.kay03:09:08

in terms of “errors”: You should generally not be using http status codes for errors from the server. Most POST to /api should “succeed”, and most API errors should be targeted data responses to EQL (e.g. a response to a mutation within the transit protocol itself). status-based errors are meant to be an indication that the server itself is somehow screwed.

jimrthy03:09:54

Thank you for the clarification. I didn't intend to use an http status code here. It just turned up while I was wiring things together and seemed like a potential future pain point for other newbies.

tony.kay03:09:25

CHANNEL: so, I’m considering making the keyframe renderer the default and the ident-optimized renderer an override. I’m not actually sure the optimizations are dramatically better in the new code base, and the programming model is certainly more painful as a result (follow-on reads and indicating derived data refreshes has always been my least favorite aspect of the entire system). I thought the new ident-optimized render would make that less painful, but it really doesn’t, since derived data in parents cannot be auto-detected. If anyone has ported anything of significance to F3 and can try the keyframe render to see what they see in terms of performance I’d appreciate it. I’m going to do the same with the projects I have here. Using the keyframe renderer would rely on the query engine being fast (it is) and the shouldComponentUpdate eliding most of the tree (it does)…and doing so would completely eliminate the need for follow-on reads, refresh declarations, etc (though you’d still have to be querying for the data that is changing in some way). My preliminary measurements show the keyframe to be a little slower, but not unreasonably so.

👍 24
jimrthy03:09:22

There's at least one other piece to the puzzle: I set up pedestal's automatic content-negotiation interceptor. Since the request doesn't specify an accept header, it's defaulting to application/json. I'm not sure yet whether this will sort itself out or if I need to override the call to fulcro-http-remote with request-middleware. It seems worth a "just in case" mention.

jimrthy02:09:13

Following up, in case anyone else runs into these sorts of issues: a major part of my problems (after I fixed the fundamentally broken server) came from the way fulcro's api-middleware/generate-response works. That gets called by handle-api-request. It's hard-coded to set the "Content-Type=application/transit+json" header in the response, but it doesn't do the serialization. So, when the interceptor chain got to the serialization interceptor, it didn't do anything because it uses this header as a signal that the serialization had already happened. (I think this behavior is pretty common). So the body map worked its way back out to whichever layer in Pedestal handles its default serialization, and it went back to the browser as...I can't remember now whether it was JSON or EDN. Either way, Fulcro couldn't parse it.

jimrthy02:09:15

(To be clear: I wouldn't expect anything to successfully parse the garbage I was sending)

jimrthy03:09:16

This is the first time I've looked at ghostwheel. It looks to me as though http-remote/fulcro-http-remote was meant to be defined with >defn rather than defn: I'm pretty sure there's a spec after the parameter vector.

tony.kay03:09:32

@jimrthy Some of the functions I had under gw and backed out, but left the specs…they don’t really hurt anything.

tony.kay03:09:52

The specs in the network layer aren’t quite right, and I have not had time to go back and tune them up.