Hi there!
I have a question. Why do you use this ugly syntax:
class HelloWorld < HyperComponent
render(DIV) do
# try changing 'world' to your own name
H1 { 'Hello world' }
P(class: 'green-text') { "Let's gets started!" }
end
endinstead of:
class HelloWorld < HyperComponent
render(div) do
# try changing 'world' to your own name
h1 { 'Hello world' }
p(class: 'green-text') { "Let's gets started!" }
end
end
actually you example sort of shows the point. In the top example DIV/H1/P are all colored blue so they standout.
But of course the nice thing about Ruby (and Hyperstack) is we are not too opioniated. If you really want to change it, its not too hard. Actually I think there is a module you can include in your application Hyperstack Class that changes it :-)
But one of things a lot of us hyperstackers really dislike about the JSX world is that when you read code there are very few syntactic hints to help make the code quickly understandable. Everything is a function call, and a bunch of curly brackets.
All that said, its a good question you raise!
I see, but as a ruby developer when I see UPCASE words I know that are
CONSTANTS and it feels strange, very strange because CONSTANTS they are made to be always the same. But in Hyperstack it has a method. If the only things that maters here is the color to see quickly what is what, you can install a plugin in your editor to recognize the framework/language you use and change the color in that context.
If it makes you feel better in fact each component (whether its a builtin tag, or an application defined component) is in fact a class (i.e. constant), and saying
MyComponent(...) is shorthand for MyComponent.insert(...)
And the second question I have is why you are passing a DIV to render?
class HelloWorld < HyperComponent
render(DIV) do
# try changing 'world' to your own name
H1 { 'Hello world' }
P(class: 'green-text') { "Let's gets started!" }
end
endmaybe it would be better:
class HelloWorld < HyperComponent
render do
div do
# try changing 'world' to your own name
h1 { 'Hello world' }
p(class: 'green-text') { "Let's gets started!" }
end
end
end
You can say the latter
its just that every render MUST generate a component, so we give the programmer the option of saving a nesting level.
Thank you. Keep up with your good :D
bye
bye
and BTW your second question about render(DIV) would be really good on stack-overflow. its very helpful to us to build out these questions in stackoverflow. Thanks!
@mpantel hey good job on the answer. Can you upvote that guys question? I don't know why it got down voted! But I see that one of the editors edited your answer.... so the more people that do this, the more curiosity we are going to get!
why does it have to be:
class HelloWorld < HyperComponent
render(DIV) do
# try changing 'world' to your own name
H1 { 'Hello world' }
P(class: 'green-text') { "Let's gets started!" }
end
endinstead of
class HelloWorld < HyperComponent
DIV do
# try changing 'world' to your own name
H1 { 'Hello world' }
P(class: 'green-text') { "Let's gets started!" }
end
endwell if you want to try it, this patch seems to work... no specs yet, but:
# add to your HyperComponent base class
class << self
alias :my_original_meth_missing method_missing
def method_missing(name, *args, &block)
if const_defined?(name) &&
(klass = const_get(name)) &&
((klass.is_a?(Class) && klass.method_defined?(:render)) ||
Hyperstack::Internal::Component::Tags::HTML_TAGS.include?(klass))
render(klass, *args, &block)
else
my_original_meth_missing(name, *args, &block)
end
end
end
class HelloWorld < HyperComponent
H1 { 'Hello world' }
P(class: 'green-text') { "Let's gets started!" }
end
besides if the DIV takes params you would have to add it...
I'm not expecting there to be a DIV if I read the above.
github stars +13 (5%) https://star-history.t9t.io/#hyperstack-org/hyperstack
hotframe works +3.5 points (its a log scale) https://hotframeworks.com/frameworks/hyperstack
@/all I am seeing a feedback loop here, and again the easiest way IMHO to help is to ask those basic SO questions. Even simple stuff you know the answer too but were at time puzzled by, gives us a lot of exposure. Please take 10 minutes of your time today and ask a question! and then answer one too!
@/all once you start looking you see a post like this about every other day: https://chanind.github.io/rails/2019/03/28/why-i-miss-rails.html
lots of rails people looking for hyperstack it seems
@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?
but if everyone feels better keeping them as instance variables I can live with that too.
well @barriehadfield actually no. The reason was simply so that one could easily tell the difference between param, local method or variable, and instance data.
we need to come up with better ways to understand when, why, where and how state is mutated.