clearwater-rb / bowser Goto Github PK

Requiring browser/http is not enough, you need to require also bowser/event_target witch can be fixed quick.

Hey, just tried to use this lib instead of opal-browser. But I miss one thing. I can't convert Bowser::Element to native element. Maybe you should add include Native to classes like Element, Document etc. What do you think ?

Element objects currently have a pretty limited number of methods and fall back to using some method_missing magic to delegate to native properties. This helps keep application JS payloads small by not defining every possible type of element and wrapping all of their methods/properties. This is fine for anything that returns primitive values (numbers, strings, or booleans), but I've begun working on apps that require a bit more functionality from the elements we're using, such as <video>, which have more complex properties.

The easiest solution I can think of is to add other files to require to extend the functionality. For example, if you want to handle some of the more advanced <video> functionality, such as HTMLMediaElement.prototype.buffered (find out which segments of an audio or video have been loaded from the server), you could add this to your app (hypothetically, that is; it does not yet exist):

require 'bowser/element/media'

This could add methods to support the buffered property to the Element class. We already added support for some <input /> element properties, but that's not ideal. It makes them available on every element. This can become problematic if there are multiple types of elements that have the same property names that need to do different things.

This hasn't been a problem because there probably aren't many different types of elements that have files or checked properties. But if there are (are there any? I honestly don't know), we'll need to be able to handle them.

I'm proposing some type of DSL to adding methods for specific element types. For the <video> example:

module Bowser
  class Element
    # Add for all media elements
    tag :video, :audio do
      def buffered
        TimeRanges.new(`#@native.buffered`)
      end
    end
  end
end

This way, it would invoke buffered only for Bowser::Element instances that wrap video and audio elements. For instances wrapping other element types, you'd get a NoMethodError as expected. As far as implementation goes, this could define an element subclass, and then Element.new could check these subclasses on instantiation. Something like this:

class Element 
  @types = Hash.new { |h, k| h[k] = Class.new(self) }
  def self.tag(*types, &block)
    types.each do |type|
      @types[type].class_exec(&block)
    end
  end

  # Return the subclass specified for this tag type
  def self.new(native)
    type = @types.fetch(`native.tagName`) { return super }
    type.new(native)
  end
end

it seems that Bowser::ServiceWorker::Promise does not implement Promise.when as shown in http://opalrb.org/docs/guides/master/promises.html

Composing Promises

Promise.when can be used to wait for more than 1 promise to resolve (or reject). Lets assume we wanted to get 2 different users:

first = get_json '/users/1.json'
second = get_json '/users/2.json'

Promise.when(first, second).then do |user1, user2|
  puts "got users: #{user1}, #{user2}"
end.fail do
  alert "Something bad happened"
end

This will likely have a few challenges associated with it. Specifically, self in a WebWorker points to the global context (like window in the UI thread), but Opal overrides it in all compiled Ruby code. This may mean it will need to be written completely in JS (not even contained within a Ruby file).

What I'd like is to be able to do something like this:

Main app

require 'opal'
require 'bowser/worker'

worker = Bowser::Worker.new('worker.rb')
worker.on :message do |event|
  puts event.data # prints "lol" to the console
end

worker.post_message "LOL"

worker.rb

require 'opal' # Yeah, it'll most likely need its own Opal runtime. :-\
require 'bowser/worker/process' # Should not be the same file the main app loads, so we'll need to figure out where to put this.

Bowser::Worker.on :message do |event|
  post_message event.data.downcase # Multithreaded downcasing FTW
end

Main things:

• Proxy JS MessageEvent with a Bowser::Event on both sides. It's possible a lot of the message-passing code will be identical on both sides, now that I think of it.
• A WebWorker is more like how we think of processes rather than threads. No memory is shared between the two. This will need to be documented.
• Only JSON primitives can go between threads.
  • We may need to JSON.dump whatever gets passed in (or to_n, whichever is more reliable and/or consumes less CPU/RAM). Maybe allow native objects through unmodified. Cross-browser benchmarks needed before any optimization happens.
  • Worker#post_message will need to warn if anything other than a Hash, Array, String, or Number is passed to it. Raising an exception might be a good idea, too, but all Ruby objects can come through, but it will have its constructor/prototype properties mangled.

If we can solve this, supporting ServiceWorker will be a nearly identical process.

Request to add #method_missing to Bowser::Window that falls back to native properties, same as Clearwater::Component.