These are chat archives for opal/opal

27th
Mar 2015
Can Edremitoglu
@cantonic
Mar 27 2015 01:31
@elia thx for the answer
what do you guys think of extending opal-jquery’s Element#expose so one can define a custom alias name so you can do Element.expose :fullCalendar, :full_calendar in order to avoid having camel case ruby method for example ?
Kurtis Rainbolt-Greene
@krainboltgreene
Mar 27 2015 02:26
Looks like Opal::Processor.source_map_register has gone?
I don't see it in the changelog.
Can Edremitoglu
@cantonic
Mar 27 2015 02:35
@krainboltgreene it has been removed in #773
Kurtis Rainbolt-Greene
@krainboltgreene
Mar 27 2015 02:39
Christ. Slap me if I ever have to write something that depends on Sprockets.
Kurtis Rainbolt-Greene
@krainboltgreene
Mar 27 2015 03:42
@elia: Seem to be having a odd compile situation: https://gist.github.com/krainboltgreene/f36eb99799336e00a43f
Didn't realize it would spam the channel, sorry.
Also realized it was a thing that I did wrong, not something with the compiler. It's really hard to adjust to this transpiler situation. Trying to figure out where the problem is really located, not because Opal is dumb about it but because I don't know the context it's reporting in.
Can Edremitoglu
@cantonic
Mar 27 2015 09:38
hmm… I cannot get rails to render a create.js.opal file. create.js works fine. Using the .js.opal extension leads to a 500 error without any further explanationation in development.log as well as no javascript console errors.
David Chang
@zetachang
Mar 27 2015 09:38
@krainboltgreene open up an issue here (zetachang/react.rb#14) for supporting React Native in react.rb
Kurtis Rainbolt-Greene
@krainboltgreene
Mar 27 2015 09:39
@cantonic I believe the standard is create.js.rb?
@zetachang I just got started using react.rb, which is wonderfully done btw.
David Chang
@zetachang
Mar 27 2015 09:40
@krainboltgreene Glad to hear, thanks! :wink:
Can Edremitoglu
@cantonic
Mar 27 2015 09:44
@krainboltgreene I think it isn’t when using opal for server javascript responses. I get a “missing template” error when using js.rb and this section of the opal-rails README also indicates to use js.opal
Kurtis Rainbolt-Greene
@krainboltgreene
Mar 27 2015 09:45
Hmm, thought I saw a comment recently about using .js.rb.
Interesting.
Either way, I bet there's a better way to debug the sprocket part of the request.
@cantonic: Try with <%= javascript_include_tag "application", :debug => true %>
Can Edremitoglu
@cantonic
Mar 27 2015 09:46
@krainboltgreene yes, usually you use .js.rb for opal files in app/assets/javascripts, but it doesn’t work for js template files in app/views
thx. will try that
Kurtis Rainbolt-Greene
@krainboltgreene
Mar 27 2015 09:47
Oh crap, sorry, somehow missed template views.
I've never been a fan of app/view/*.js files, so I'm no help.
Can Edremitoglu
@cantonic
Mar 27 2015 09:49
@krainboltgreene i just start becoming a fan of them. previously I used client side ajax calls and made json responses handled by the client, but using server js responses has a lot of advantages over the other approach for me.
Can Edremitoglu
@cantonic
Mar 27 2015 10:15
oh nice, somehow it is working now. Don’t know what caused the error unfortunately
Can Edremitoglu
@cantonic
Mar 27 2015 10:29
and back to error again… weird. is it possible that the latest Sprockets changes prevent files like create.js.opal from working?
Can Edremitoglu
@cantonic
Mar 27 2015 10:50
ok, after disabling forgery protection I at least get an error message: stack level too deep in create.js.opal. The method causing it is alert 'foobar'
narrowed it down to the instance variables set in the controller’s #create action. They are causing a stack level too deep error. When I remove them in the #create action it is working fine.
Adam Beynon
@adambeynon
Mar 27 2015 10:58
@cantonic Im not sure of exactly how it works, as @elia did the templating stuff for rails
it looks like locals are handled via #to_json - so maybe there is something bad in one of the models getting converted to json - recursive objects maybe
Can Edremitoglu
@cantonic
Mar 27 2015 11:01
@adambeynon thank you. I assume the same.
Elia Schito
@elia
Mar 27 2015 13:03
@krainboltgreene @router = Ghostryder::Router.new does it work with @router = ::Ghostryder::Router.new?
if it works on MRI without the double colon please open an issue
@cantonic didn't use app/views templates in a while, can you try applying to_json to all ivars in the controller manually, if it breaks there that's the issue
Can Edremitoglu
@cantonic
Mar 27 2015 13:16
@elia: the controller handles it without any problems
Elia Schito
@elia
Mar 27 2015 13:17
@cantonic can you post some code? (a gist in private chat is ok)
Can Edremitoglu
@cantonic
Mar 27 2015 13:22
sure
Elia Schito
@elia
Mar 27 2015 13:33
can you try replacing create.js.rb with this create.js.erb?
<%= JSON.parse(local_assigns.to_json).map { |key, val| "#{key} = #{val.inspect};" }.join %>
<%= JSON.parse(@_assigns.to_json).map { |key, val| "@#{key} = #{val.inspect};" }.join %>
Can Edremitoglu
@cantonic
Mar 27 2015 13:45
@elia that raises the same error like create.js.opal. Hope that helps for further investigation :)
Elia Schito
@elia
Mar 27 2015 13:45
:+1:
Can Edremitoglu
@cantonic
Mar 27 2015 15:42
@elia is the stack level too deep error happening because the template handler tries to transform the instance variables and all their methods etc into json? If so, could we change the template handler to perform to_json only on the instances attributes? or maybe even totally remove the instances from automatically being available and instead pass local variables to the js.opal file if necessary?
Elia Schito
@elia
Mar 27 2015 15:48
@cantonic simplest solution would be to set those vars only when needed by the view, but that's probably my hate for passing data via ivars that's talking here
otherwise we could try to detect if they're used in the view
hackish but probably do-able
last option–which i don't like– would be to make it a config flag
Can Edremitoglu
@cantonic
Mar 27 2015 15:57
@elia I like the first solution. saves resources, even though one could expect view templates to have access to ivars since they are also available in html or js.erb template views.
@elia hey, what about .js.opal.erb? :D
Elia Schito
@elia
Mar 27 2015 15:58

.js.opal.erb

what do you mean?

for the first solution the only problem would be detecting locals, but probably if locals are set we can trust it's done intentionally
@cantonic can you open an issue on opal-rails as a reminder for this change? feel free to copy/paste the whole transcript :)
Can Edremitoglu
@cantonic
Mar 27 2015 16:01
@elia js.opal.erb was meant as a joke so you could do Element[“#file_<%= @file.id %>”] for example :)
actually that wouldn’t be too bad… we wouldn’t have to compile the whole instance variable and one could use erb to get values from an instance variable into the code before it gets compiled. Additionally to this you could pass local variables to the template like usual and described in https://github.com/opal/opal-rails#as-a-template
Elia Schito
@elia
Mar 27 2015 16:03
@cantonic lol, yeah, would make sense if it wasn't so meta… <inception-emoji-here>
Can Edremitoglu
@cantonic
Mar 27 2015 16:03
hehehe
i would say: if you need an instance variable or parts of it you should pass it in like render type: :js, locals: {post: @post}
will create an issue for it
Elia Schito
@elia
Mar 27 2015 16:09
I think locals: should still produce locals in the view, but skipping unwanted ivars makes sense, even if it would break crazy code such as class << self; attr_accessor :foo; end; p foo
@adambeynon any thoughts on this?
Adam Beynon
@adambeynon
Mar 27 2015 16:27
@elia, @cantonic I like the opt-in approach using locals: …
Can Edremitoglu
@cantonic
Mar 27 2015 16:28
@elia, @adambeynon in that case it is as easy as removing https://github.com/opal/opal-rails/blob/master/lib/opal/rails/template_handler.rb#L24-L28 right?
Elia Schito
@elia
Mar 27 2015 16:32
@cantonic :+1: yes and update line 13, wanna do a PR for that?
Can Edremitoglu
@cantonic
Mar 27 2015 16:33
yep. i’ll take care of it right now
just want to do one or two tests before to make sure the ivars are really breaking it
Can Edremitoglu
@cantonic
Mar 27 2015 16:48
wow, when trying to debug the template handler my editor crashes… must have to do with the “stack level too deep” error which somehow leaves the question if there is just a logical mistake in the handler...
SystemStackError - stack level too deep:
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `block in as_json'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `each'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `map'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `as_json'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:50:in `as_json'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `block in as_json'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `each'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `map'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:159:in `as_json'
  activesupport (4.1.9) lib/active_support/core_ext/object/json.rb:50:in `as_json’

… and so on
Elia Schito
@elia
Mar 27 2015 16:59
seems there's just a loop in as_json, you can check lib/active_support/core_ext/object/json.rb at the stacktrace lines to see which class is that as_json from
Can Edremitoglu
@cantonic
Mar 27 2015 17:05
@elia does this have to do with it? rspec/rspec-rails#1309
excerpt from rspec/rspec-rails@9f6f9bd : Rails adds a nearly global monkey patch to make converting objects into
JSON easier. It adds both to_json and as_json methods on nearly all
core object types; including Object but not BasicObject.
Elia Schito
@elia
Mar 27 2015 17:08
yep, tldr, but given it's recursive that's probably the culprit
Can Edremitoglu
@cantonic
Mar 27 2015 17:10
okay. maybe I can solve it with a little help of you from time to time :)
Elia Schito
@elia
Mar 27 2015 17:11
sure thing

make sure the ivars are really breaking it

forgot to mention that the problem is not ivars per se but the to_json transformation, going from ivars to locals (which is good anyway) won't help as locals are still treated with to_json

Can Edremitoglu
@cantonic
Mar 27 2015 17:15
@elia so render type: :js, locals: {directory: @directory} should produce the same error, right?
Elia Schito
@elia
Mar 27 2015 17:16
I think so
Can Edremitoglu
@cantonic
Mar 27 2015 17:17
yeah it does
in that case removing Opal::Rails::TemplateHandler#assigns wouldn’t solve the problem since people would run into that problem pretty quickly.
Elia Schito
@elia
Mar 27 2015 18:07
@cantonic properly implementing to_json would solve, helping understand that to_json will be called on all ivars/locals is another option, but I don't know how we could do that
Can Edremitoglu
@cantonic
Mar 27 2015 18:08
me neither :(
Can Edremitoglu
@cantonic
Mar 27 2015 19:19
ok, the error happens for @_assigns, not for local_assigns. the latter can call to_json without problem. I am removing the assigns method like we discussed earlier
Elia Schito
@elia
Mar 27 2015 19:47
K, was hacky (but cool) from the beginning
Elia Schito
@elia
Mar 27 2015 20:29
@cantonic looking again at the code, seems odd that there's no difference between using ivars and locals, just saying…
Can Edremitoglu
@cantonic
Mar 27 2015 20:29
@elia well the locals are simple and not as deeply nested as ‘@_assigns'
but removing the ivars and going with locals is also not optimal. i passed in an activerecord object as a local, but in the template file it is just a json string. You cannot use its methods which you can with erb
Elia Schito
@elia
Mar 27 2015 20:31
it's a different beast
The idea is that youre passing (controlled) attributes to opal and there possibly use them to instantiate a clientside model
you can wrap them in OpenStruct or Struct
you can also pass the values you need as locals/ivars calling the methods (aka preparing the data) in the controller
Can Edremitoglu
@cantonic
Mar 27 2015 20:37
yep right. you can get done what you need to get done but in a more inconvenient way as with coffee+erb templates. somehow at some time it would be good to be able to be able to use the locals and ivars like you can with erb I think.
@elia using OpenStruct? like render locals: {post: OpenStruct.new(@post) ?
Elia Schito
@elia
Mar 27 2015 20:38
I'm ok with that as long as the solution is not super confusing, the problem is that you're mixing server and clientside stuff
it's a problem of serialization/deserialization; would be serialized in MRI and deserialized in Opal
the safest thing I came up was hash/array/…->json->hash/array/…
as all the types used by json are guaranteed to be available on the client,
not sure how it could play out with OpenStruct
Can Edremitoglu
@cantonic
Mar 27 2015 20:41
therefore I thought about bringing erb into the game so you can use both: locals for client side stuff and erb for server side
you could prepare your locals in the controller but also quickly do a <% if @post.new_record? %> if you quickly need it
Elia Schito
@elia
Mar 27 2015 20:42
if you want to take a knack at implementing that :+1:, after all anyone adding .opal.erb as an extension is supposed to know what he's doing
I'll help of course, even if I'm not completely aware of how chaining multiple templates works in app/views