Syntax for functional/static/pure components

[catmando]

Currently we don't have any syntax in the DSL to define and then use functional components. We access native static components, but the DSL simply wraps them in a normal component.

What problems do react functional (static) components actually solve? Skim these articles and you will see its mainly to do with how relatively difficult it is to define a component in React, compared to a simple function.

https://blog.logrocket.com/react-functional-components-3-advantages-and-why-you-should-use-them-a570c83adb5e

https://hackernoon.com/react-stateless-functional-components-nine-wins-you-might-have-overlooked-997b0d933dbc

The Hyperstack DSL is already far less verbose than JSX.

If we rewrite the first example in the above blog post in Ruby its only 10 lines verses 21 for the functional component.

class HelloWorld < HyperComponent
  param :name
  def say_hi 
    alert("Hi #{name}")
  end
  DIV do 
    A(href: '#') { 'Say Hi' }
    .on(:click) { say_hi }
  end
end

Furthermore, we have other ways to accomplish the same idea built into Ruby.

It's very easy to simply add instance methods to a component:

class App < HyperComponent

  def say_hi(name) 
    alert("Hi #{name}")
  end

  def hello_world_link(name)
    DIV do 
      A(href: '#') { 'Say Hi' }
      .on(:click) { say_hi(name) }
    end
  end

  DIV do 
     INPUT(placeholder: 'what is your name?', value: @name)
     .on(:change) { |e| mutate @name = e.target.value } 
     hello_world_link(@name)
  end
end

and if we want separation of concerns we just move related methods to a module:

module Utils
  def say_hi(name) 
    alert("Hi #{name}")
  end
  def hello_world_link(name)
    DIV do 
      A(href: '#') { 'Say Hi' }
      .on(:click) { say_hi(name) }
    end
  end
end

class App < HyperComponent
  include Utils
  DIV do 
     INPUT(placeholder: 'what is your name?', value: @name)
     .on(:change) { |e| mutate @name = e.target.value } 
     hello_world_link(@name)
  end
end

In any real scenario the definition of a functional component is going to have to go someplace, and almost certainly be grouped with other components, so simply using mixin modules like the above is going to be the equivalent.

Finally here is a counterpoint to the whole functional component thing anyway:

https://medium.freecodecamp.org/7-reasons-to-outlaw-reacts-functional-components-ff5b5ae09b7c

[catmando]

One advantage of functional or pure components is that they do not have internal state. If you want to make this distinction in Hyperstack simply create a second component base class like StaticHyperComponent that does not include Hyperstack::State::Observable. This will remove all the state handling code from the component, and it will be static!!

If you really love functional components you could even go the other way: Don't include Hyperstack::State::Observable in your base HyperComponent class and then add the line include Hyperstack::State::Observable in any non-static components.

[catmando]

An additional issue though changes all this:

Only functional components can use react hooks, and react hooks are becoming increasingly popular in component libraries, so we need to do something so that these hooks can be used.

One approach would be to simply make all Hyperstack components "functional" components. I'm not sure if this is possible, but it does seem so.

• State can be implemented using the useState hook (which would probably be better)
• The rest of the life cycle hooks can also be implemented using hooks: https://reactjs.org/docs/hooks-faq.html#how-do-lifecycle-methods-correspond-to-hooks
• Except for componentDidCatch but that is okay because the way hyperstack wraps that callback is to create a wrapper component anyway.

My plan would be to leave all the component syntax exactly as is. Interesting to see if this can be made to work.

[catmando]

because of the need to use hooks, this is now on the Alpha -> Production roadmap