How about Ovto?

Meguro.rb#29
https://docs.google.com/presentation/d/e/2PACX-1vRw8tPyvVkh-QuBu1EA4IQfexwyavHy3oqQqJRYbHuj1ktRbnKYDUBs-InA2yDmcp1jze8XIvKeIRsp/pub?start=false&loop=false&delayms=3000

Transcript

1. How about Ovto?
   Meguro.rb#29
   Jul. 31, 2019
   

   View Slide

2. pp self
   ● Masataka “Pocke” Kuwabara
   ● Bit Journey, Inc. / Kibela
   https://me.pocke.me
   https://kibe.la
   

   View Slide

3. Agenda
   ● What is Opal and Ovto?
   ● How about Ovto?
   ● Deep in Ovto
   

   View Slide

4. What is Opal?
   

   View Slide

5. Opal is...
   “Opal is a Ruby to JavaScript source-to-source
   compiler.”
   https://github.com/opal/opal
   

   View Slide

6. What is Ovto?
   

   View Slide

7. Ovto is...
   “Client-side web framework for Opal”
   https://github.com/yhara/ovto
   

   View Slide

8. Ovto is...
   ● Written in Ruby (Opal)
   ● Based on Hyperapp
   ● Declarative
   ● Virtual DOM
   ● Single state
   For more information: Ovto [search]
   

   View Slide

9. The minimum example
   class App < Ovto::App
   class State < Ovto::State; end
   class MainComponent < Ovto::Component
   def render
   o ‘h1’, ‘Hello’
   end
   end
   

   View Slide

10. How about Ovto?
    

    View Slide

11. Pros
    ● Fun!
    ● Performance is enough (for me)
    ● Easy to understand
    ● Compiling process is simple
    ● Ovto.fetch
    ○ Useful, but I guess it is out of scope of Ovto
    

    View Slide

12. Fun!
    ● Write front-end with Ruby
    ● Ovto respects Ruby feeling
    ○ We can write Ovto without stress
    

    View Slide

13. Performance
    ● It works fine with a Number Place app
    ● https://puzzle.pocke.me
    

    View Slide

14. Compiling process
    ● opal --gem ovto -I lib/ lib/entrypoint.rb >
    app.js
    

    View Slide

15. Cons
    ● Only a few eco-system
    ○ No useful libraries
    ● Actions are flat
    

    View Slide

16. No eco-system
    ● I have created ovto-router
    ● I will need ovto-i18n and so on in the future
    

    View Slide

17. Actions are flat
    ● Actions update state
    ● It is flat in an App
    ● All actions should have a prefix? I do not like it!
    

    View Slide

18. Current solution for flat action
    ● Only define `dispatch` action
    ○ def dispatch(state:) state; end
    ● Call it from instance method of component
    ○ def update_something(s:)
    actions.dispatch(state: {something: s})
    end
    ● It is not the best, but it works without conflict
    

    View Slide

19. Appendix: Deep in Ovto
    

    View Slide

20. Ovto structure
    App
    Main
    Component
    State
    Actions
    Component
    Component
    Component
    Component
    Component
    Component
    Component
    

    View Slide

21. Ovto structure
    ● App has one
    ○ State
    ○ Actions
    ○ MainComponent
    ● MainComponent is a component
    ● Component has many components
    

    View Slide

22. State
    

    View Slide

23. State
    ● Ovto::App has one State
    ● All components can access to the state
    ○ except PureComponent
    ● You can nest state
    ○ Useful for SPA, middleware and so on
    

    View Slide

24. Example
    class State < Ovto::State
    item :hoge, default: “foo”
    item :tasks, default: []
    end
    

    View Slide

25. Advanced: Nested state
    class TaskState < Ovto::State
    item :tasks, default: []
    end
    class State < Ovto::State
    item :task, default: TaskState.new
    end
    

    View Slide

26. Actions
    

    View Slide

27. Actions
    ● Actions update the state
    ● Ovto::App has one Actions
    ● All components can access actions
    ● Actions has only one namespace
    

    View Slide

28. Example
    class Actions < Ovto::Actions
    def add_task(title:)
    new_tasks = TaskState.new(title: title)
    {tasks: [*state.tasks, new_title]}
    end
    end
    

    View Slide