Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 04 2018 12:19

    catmando on noreset

    initial commit refactoring now (compare)

  • Oct 01 2018 13:19

    barriehadfield on edge

    Hyperloop point to master for JS (compare)

  • Oct 01 2018 13:08

    barriehadfield on edge

    Hyperloop 0.99.1 (compare)

  • Sep 08 2018 00:40

    catmando on edge

    got tests passing again Gemfiles point to released gems (compare)

  • Sep 07 2018 23:03
    catmando closed #20
  • Sep 07 2018 23:03
    catmando closed #19
  • Sep 07 2018 23:03

    catmando on edge

    closes #19 closes #20 Merge branch 'edge' of github.c… resolved gemspec merge conflict (compare)

  • Sep 07 2018 22:49
    catmando opened #20
  • Sep 02 2018 08:34

    barriehadfield on edge

    Update README.md (compare)

  • Sep 02 2018 08:33

    barriehadfield on edge

    Update README.md (compare)

  • Aug 31 2018 09:31
    mpantel commented #12
  • Aug 28 2018 07:15
    mpantel commented #12
  • Aug 22 2018 08:00
    mpantel commented #12
  • Aug 19 2018 21:12

    johansmitsnl on edge

    Move the libv8 to running depen… Remove webdriver Remove empty helper (compare)

  • Aug 19 2018 21:06

    johansmitsnl on edge

    (compare)

  • Aug 19 2018 21:02

    johansmitsnl on edge

    Download and install the chrome… (compare)

  • Aug 19 2018 20:51

    johansmitsnl on edge

    Remove the find for the webdriv… (compare)

  • Aug 19 2018 20:51

    johansmitsnl on edge

    Include the database schema (compare)

  • Aug 19 2018 20:46

    johansmitsnl on edge

    Use find to locate the webdriver Don't set the path directly (compare)

  • Aug 19 2018 20:42

    johansmitsnl on edge

    Update the gemfile.lock (compare)

Mitch VanDuyn
@catmando
@/all new question on Stack Overflow... I spot the problem, but it would be great if somebody else wants to answer (hint just a little typo in the create_new_todo_item method)
Mohamed Ziata
@WaKeMaTTa

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
end

instead 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
Mitch VanDuyn
@catmando
@WaKeMaTTa because everything in Ruby is a method call, its nice to be able to quickly see the difference between builtin html/svg tags, application defined components, and other method calls.
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!
Mohamed Ziata
@WaKeMaTTa
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.
Mitch VanDuyn
@catmando
yeah but I don't think most editors right now would be smart enough to tell the difference. But you are correct it is a bit of a deviation from ruby syntax.
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(...)
Mohamed Ziata
@WaKeMaTTa

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
end

maybe 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
Mitch VanDuyn
@catmando
its funny we wanted to be able to say MyComponent[...] which is very normal Ruby, buttttt guess what there is a known bug in ruby where you can't pass a block to the [] method! So we had to drop that idea :-(
You can say the latter
Mohamed Ziata
@WaKeMaTTa
I didn't know about that.
Mitch VanDuyn
@catmando
   render(DIV) do 
      blat
   end

# short for

  render do
    DIV do
      blat
    end
  end
its just that every render MUST generate a component, so we give the programmer the option of saving a nesting level.
Mohamed Ziata
@WaKeMaTTa
yeah i know, but the second one is more explicit and more readable
Mitch VanDuyn
@catmando
yeah... its pretty new to us too. I am sure standard styles will come out as people use it.
Mohamed Ziata
@WaKeMaTTa

its just that every render MUST generate a component, so we give the programmer the option of saving a nesting level.

ah! okey.

Thank you. Keep up with your good :D
bye
Mitch VanDuyn
@catmando
please be sure to star us on https://github.com/hyperstack-org/hyperstack
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!
Michail!
@mpantel
@catmando done!
Siksel
@Siksel
@iamprich When you dockerized it, did you get it working with foreman or just normal rails? I'm working on my docker config now and haven't quite got either up yet
Mitch VanDuyn
@catmando
@WaKeMaTTa (@/all) you got me thinking...
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
end

instead 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
end

well 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
peterlamber
@peterlamber
cool
peterlamber
@peterlamber
I would probably add the DIV to the default too to get rid of another level
Mitch VanDuyn
@catmando
interesting idea, but I think that would be too confusing...
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.
Mitch VanDuyn
@catmando
@/all @WaKeMaTTa 's recent comment, got myself and @barriehadfield talking, and raises a couple of questions that I would love to get your input on. I put this issue in so please log your comments there:
Mitch VanDuyn
@catmando
@/all weekly exposure report:
hotframe works +3.5 points (its a log scale) https://hotframeworks.com/frameworks/hyperstack
Mitch VanDuyn
@catmando
stackoverflow +4 questions (not sure how to score this but these 4 questions have already been viewed almost 100 times today)
@/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!
Mitch VanDuyn
@catmando
@/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
Barrie Hadfield
@barriehadfield

@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_thing to @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_reader where 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.

Mitch VanDuyn
@catmando
@barriehadfield I agree about the params. Have you thought about the other alternative and that is params become accessor methods. so param :my_special_thing creates an accessor method my_special_thing. I personally like this the best for two reasons:
  1. it prevents accidental writing to a @my_special_thing which is just going to mess you up when the param gets asyncrounosuly updated.
  2. it looks like ruby (i.e. params in ruby are also indistinguishable from methods when you read the code)
  3. (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.
Michael Whobrey
@mwhobrey
i really like the idea of the params being translated to accessor methods, to me the biggest "wait wut" moment i had was not the html tags being all caps but the param transformation
Mitch VanDuyn
@catmando
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.