class HelloWorld < HyperComponent
H1 { 'Hello world' }
P(class: 'green-text') { "Let's gets started!" }
end
@peterlamber sometimes you don’t want to render a div, sometimes it needs to be another component or HTML element. A perfect example is button which is likely to be a component (Button) or an HTML tag (BUTTON or button). For this reason, HTML tags in CAPS make sense. And actually, I have got used to them. You're right, H1 is better than h1 to read and DIV or SPAN look like tags whereas their lowercase cousins do not.
The bit I have a hump with is the conversion of params from snake_case to CamelCase. I don't like it for the following reasons:
- The conversion is meant to designate that the param is immutable, but there are exceptions to this rule (Models are mutable, and params of type Proc are callable.
- There is connective friction converting a param
param :my_special_thingto @MySpecialThing which is unnecessary considering the point above - The code is less readable; :my_special_thing != @MySpecialThing, so you have to burn cycles to read it
- There is Rubu convention with
attr_readerwhere the instance variable is not converted, but available in the class as@my_special_thing - More typing!
So basically, I don't see that we get the advantage (the immutable rule does not hold), but we get the negatives .
My vote is just that the default be rfeversed: param :my_special_thign becomes @my_special_thing and if you want to change it you opt for the behaviour where it becomes @MySpecialThing
Anyway, that's what I think. I will go with whatever is decided.
- it prevents accidental writing to a
@my_special_thingwhich is just going to mess you up when the param gets asyncrounosuly updated. - it looks like ruby (i.e. params in ruby are also indistinguishable from methods when you read the code)
- (did I say 2 - I mean't three) params can be internally aliased. This allows very nice:
param :fuel_pump_on, aka: :fuel_pump_on?
observe works), so I am ready to re-write those now
param_accessor_style :accessors
