On 12 June 2017 at 11:28, Sam Ruby <ru...@intertwingly.net> wrote:
> On Mon, Jun 12, 2017 at 5:29 AM, sebb <seb...@gmail.com> wrote:
>> On 12 June 2017 at 03:36, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Sun, Jun 11, 2017 at 7:16 PM, sebb <seb...@gmail.com> wrote:
>>>> On 11 June 2017 at 00:14, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>> On Sat, Jun 10, 2017 at 6:39 PM, sebb <seb...@gmail.com> wrote:
>>>>>> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <seb...@gmail.com> wrote:
>>>>>>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <seb...@gmail.com> wrote:
>>>>>>>>>> On 10 June 2017 at 16:58, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>>>>> On Sat, Jun 10, 2017 at 11:48 AM, sebb <seb...@gmail.com> wrote:
>>>>>>>>>>>> On 10 June 2017 at 15:57, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>>>>>>> On Sat, Jun 10, 2017 at 10:27 AM, sebb <seb...@gmail.com> wrote:
>>>
>>> [snip]
>>>
>>>>>>
>>>>>> I don't know where to start with ExecJS.
>>>>>
>>>>> Neither do I.
>>>>>
>>>>>> But it ought to be possible to use window.onerror or similar in the
>>>>>> generated code to catch/display the error to the user.
>>>>>
>>>>> There is no window object on the server.
>>>>>
>>>>>> Or wrap the generated JS in try/catch.
>>>>>
>>>>> And do what?
>>>>
>>>> Display err.stack
>>>>
>>>> for example:
>>>>
>>>> try {
>>>> ...
>>>> } catch(err) {
>>>> alert(err.stack);
>>>> console.log(err.stack);
>>>> etc.
>>>> }
>>>>
>>>> However I've no idea how to add that to the generated code.
>>>>
>>>> It might be worth seeing what the following gives:
>>>>
>>>> rescue ExecJS::ProgramError => e
>>>> Wunderbar.error e.inspect
>>>>
>>>> It may be that the error object has more info embedded.
>>>
>>> With no window object on the server, there is no window.alert. There
>>> is no console object on the server either. Lets try this the other
>>> way. I've included a sample program below with no dependencies other
>>> than execjs:
>>>
>>> require 'execjs'
>>>
>>> source = %{
>>> function test () {
>>> try {
>>> var x = null;
>>> x.y();
>>> } catch(err) {
>>> alert(err.stack);
>>> console.log(err.stack);
>>> }
>>> }
>>> }
>>>
>>> context = ExecJS.compile(source);
>>> context.call("test()");
>>
>> Running that with ruby fails with the error:
>>
>> test ((execjs):7:7): ReferenceError: alert is not defined
>> (ExecJS::ProgramError)
>>
>> However the generated app.js file contains code of the form:
>>
>> .catch(function(error) {
>> alert(errror);
>> jQuery("#confirm").modal("hide");
>> self.setState({disabled: false})
>>
>> which *does* use alert.
>
> That code is contained within logic that is known to only run on the client.
>
>> Though why it uses errror instead of error is unclear.
>
> Clearly a typo on my part. I've pushed a fix. Good catch!
>
>> I don't know how the alert gets added to the generated js, but if that
>> could be updated to change the alert and/or wrap the code in a
>> try/catch block it might solve the issue.
>
> If you look at the fix I just pushed, you will see the code that gets
> translated into the code mentioned above.
>
> As to adding another try/catch block: again the question is do what
> within that try/catch block? On the client, you get a nice traceback
> in your console. On the server, there is no access to an alert or
> console.log function.
>
>> ==
>>
>> As to improving the server code reporting, it looks as though it may
>> be sufficient to add
>>
>> Wunderbar.error e.backtrace
>
> Getting a stack traceback of the ruby stack will only tell you that
> you are calling render. At most, it will help you identify which page
> the error occurred on, information that already is in the server log.
But as I noted earlier, it's not at all obvious how to find that info
from the error message.
There are various lines containing file names/URLs, but there's no
obvious connection with the error message except they have the same
App number.
It would help if:
1) the error was identified as a JS error
2) the source file was logged as wll.
> There would be value in showing a javascript traceback, but to date
> I've not figured out a way to do that. If you experiment with the
> smalls script I provided and find a way to show the javascript
> traceback with that code, I would be very interested.
I cannot get the sample code to run successfully, even without forced errors.
I tried
>>>
require 'execjs'
source = %{
function test() {
return 123;
}
}
context = ExecJS.compile(source);
context.call("test()");
<<<
And I get
eval (eval at <anonymous> ((execjs):6:8), <anonymous>:1:9): TypeError:
test(...).apply is not a function (ExecJS::ProgramError)
I have now found I get a better result with:
puts context.eval('test()'); => 123
which seems closer to what Wunderbar does.
However adding alert to the JS source breaks the compilation.
Yet Wunderbar clearly is able to generate JS containing an alert call.
Another aspect I don't understand is why the code is executed on the server.
I would expect it to be generated on the server and then returned to
the client for evaluation.
>> after
>>
>> https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/react.rb#L133
>>
>>> - Sam Ruby
>
> - Sam Ruby
