Our long term plan to make GitLab as fast as possible with Vue and Webpack

Post by nkohari » Tue, Feb 07, 2017, 5:24 PM UTC

duncanawoods wrote: post #209

nkohari wrote: post #206

Earlier quoted context omitted.

Ternary operators should never be nested, whether you're using JSX or not. If you have that many conditionals you should use variables and/or decompose the optional pieces into sub-components. Pretty much any time you have a tag that has a huge number of attributes, it's a smell that you need to decompose something. Variable assignment is the simplest answer, which takes advantage of the fact that null or undefined v…

I think this proves lhorie's point. Markup syntax is dominated by code when you are building complex dynamic apps instead of static documents. What do you really gain by putting angle brackets around Avatar instead of calling a function? FWIW I believe new react devs are slow to realise they can use local variables like this because JSX looks like it is doing string templating instead of object instantiation.

    const Dashboard = (props) => {
      const {user} = props;
      let link;
      if (user) {
        link = (
          
            
            {user.name}
          
        );
      }
      return (
        
          {link}
          ...some other content...
        
      );
    };

Post by duncanawoods » Tue, Feb 07, 2017, 5:41 PM UTC

nkohari wrote: post #232

duncanawoods wrote: post #209

Earlier quoted context omitted.

I think this proves lhorie's point. Markup syntax is dominated by code when you are building complex dynamic apps instead of static documents. What do you really gain by putting angle brackets around Avatar instead of calling a function? FWIW I believe new react devs are slow to realise they can use local variables like this because JSX looks like it is doing string templating instead of object instantiation.

The example I gave was simplistic, but the value of JSX is the ability to easily nest elements. For instance, let's take my previous example and say we're creating a profile link: const Dashboard = (props) => { const {user} = props; let link; if (user) { link = ( {user.name} ); } return ( {link} ...some other content... ); }; If you want, you could create a `createProfileLink()` function, or you could create a `Profi…

    const Dashboard = (props) => {
      const {user} = props;
      let link;
      if (user) {
        link = 
            DOM.a({href: "..."},
                Components.Avatar(user),
                DOM.span(user.name));
      }
      return 
        DOM.div(link, ...some other content);
    };

Post by realharo » Tue, Feb 07, 2017, 5:56 PM UTC

sandGorgon wrote: post #142

realharo wrote: post #136

Earlier quoted context omitted.

I don't know, that UI looks a little too "mobile first" to me (for something I would only use on my computer). EDIT: also, the colors seem quite dull from those screenshots

heh heh.. no real way to win. https://gitlab.com/gitlab-org/gitlab-ce/issues/6057

Post by ZenoArrow » Tue, Feb 07, 2017, 6:14 PM UTC

YorickPeterse wrote: post #229

ZenoArrow wrote: post #71

I'm not aware of the performance bottlenecks with GitLab, but are there any plans to speed up the backend as well, such as moving to a faster Ruby implementation?

We have no plans to move to another Ruby implementation, primarily because Ruby itself is not yet a bottleneck for us.

Post by rmetzler » Tue, Feb 07, 2017, 6:17 PM UTC

jmtulloss wrote: post #207

Bahamut wrote: post #201

Earlier quoted context omitted.

className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.

It was named that to match the DOM api[0], which React does whenever possible. The DOM api is probably named for the reason you state. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...