Closed kevanstannard closed 4 years ago
This appears to be working. Is it correct to be passing the res
argument in each of the Response
function calls?
let sendResponse = (_error, html) => {
Response.sendString(html, res)
}
let renderDefault = (_error, html) => {
let data: Js.Dict.t<string> = Js.Dict.empty()
Js.Dict.set(data, "body", html)
Response.render("default", data, sendResponse, res)
}
let data: Js.Dict.t<string> = Js.Dict.empty()
Js.Dict.set(data, "name", "Tobi")
Response.render("user", data, renderDefault, res)
Thanks
Response.render("default", data, sendResponse, res)
should compile to exactly the same as res.render("default", data)
Thanks @ncthbrt
If I change the code from this:
Response.render("default", data, sendResponse, res)
to this:
res.render("default", data)
Then unfortunately I see a compile error:
The record field render can't be found.
Yes. That would be expected. bs-express
bindings aims to provide an idiomatic functional interface over express.
Moving the response as an argument to a function rather than an object with methods is more inline with fp practises in that it can more easily compose with piping and so on. However Response.render("default", data, sendResponse, res)
should compile to the form expected above at zero or near zero cost.
@ncthbrt thanks for explaining.
Since the strategy above seems to be working fine, I'll close this issue.
Hi, does
bs-express
support nested view rendering? For example, in Express it would be something like this: