Tei posted:

I dont think is a good idea to use ternary for long expressions / multiline.

Ternary exist to have a more compact format where is still readable. To protect the surrounded code from some meaningless if that will only obscure why the code is doing what is doing.

Anyway nothing is forbidden, everything is free, have fun and happy coding. Somebody somewhere has found CSS is turing complete and is compiling a bitcoin miner for it.

rohan posted:

React 16 introduced the <Fragment> tag, which goes some way to fixing this -- it groups the nodes for return but doesn't render, so the resulting DOM tree doesn't have unnecessary parent divs.

(React 16.2 introduced <> as a shorthand notation, as well.)

Anony Mouse posted:

code:

render() {
	return (
		<div>
			{
				this.props.foo
				?
					<div>
						<h1>bar</h1>
						<p>baz</p>
					</div>
				:
					[]
			}
		</div>
	);
}

quote:

it's readable for me cause it's what I'm used to by now

HaB posted:

code:

var fart = someBool
    ? some really long expression
    : some really long expression

or sometimes

var fart = 
    someBool
    ? some really long expression
    : some really long expression

I can almost tolerate this, except it seems like such a personal style quirk that who ever comes along afterwards is bound to add their own personal style to it and it's just gonna get worse and worse. A MUCH easier rule is: no multiline ternaries. What you lose in typing an extra 10 characters you more than make up for in readability.

rohan posted:

Christ, this. I'm working with someone who I think has just discovered ternaries and the entire codebase is littered with things like:

code:

const foo = isActive
                     ? 'show'
                     : 'hide';

It's taking a lot of self-control not to go through and change everything to <Component className={ isActive ? 'show' : 'hide' } />

a hot gujju bhabhi posted:

To be clear, my goal IS readability. I'm not worried about typing extra characters. As mentioned there are other conceptual benefits to using ternaries too. I think the examples I used are perfectly readable in the form that I posted them.

The multiline thing for that example is just stupid, but otherwise that's a perfect use-case for a ternary I would have thought? Is it just the multiline thing that bothers you? Because that I get.

HaB posted:

Perfectly readable to you because you are used to writing them and reading them that way. Other devs you work with might not think so. Once again - every shop I have worked in would fail a multiline ternary on a code review, because you gain NOTHING by using multiline ones.

HaB posted:

There's not a conceptual difference between ?: and if/else at all. ?: is designed to be a quick single line shorthand:

a hot gujju bhabhi posted:

I doubt they're very common in JavaScript (and I don't use them there) but they're not uncommon in C# which is what I code in day-to-day. You personal workplace anecdotes aside, I didn't make this up and it is a thing I've seen other people do also.


Of course there is, and I already explained this. A ternary signals immediately to the reader that the left hand side will be assigned something because that way a ternary does, an if/else statement doesn't because it's used for controlling logical branching. I don't understand how you can honestly try to claim there's no conceptual difference between the two.

HaB posted:

Because there literally isn't. This code is equivalent:

code:

var a = test ? 1 : 2;

vs

var a = 1;
if(test) {
    a = 2;
}

So you explain to ME the difference. Ternary is nothing but shorthand/syntactic sugar.

Gildiss posted:

Another gem in the ESLinting mines.

code:

function(a,b){
    return (((typeof a.lastName === 'string' ? a.lastName.toUpperCase() : '') < (typeof b.lastName === 'string' ? b.lastName.toUpperCase) : '')) ? -1 : (((typeof a.lastName === 'string' ? a.lastName.toUpperCase() : '') > (typeof b.lastName === 'string' ? b.lastName.toUpperCase) : '')) ? 1 : 0));
}

Just because you can do something doesn't mean you should.

E: lol the blame shows this as being from one of the contracting teams tech leads.

Tei posted:

I must write this because I am not a good person

code:

var someBool = 0;
...

function getErrorMessage(){
   return "<h1>Something bad</h1>";
}

function getOkMessage(){
  return "<span>Okay, bro</span>";
}

var messages = [  getErrorMessage,  getOkMessage ];

// Any "If" can be turned into a array
var fart = messages[someBool]();

Anony Mouse posted:

code:

render() {
	return (
		<div>
			{
				this.props.foo
				?
					<div>
						<h1>bar</h1>
						<p>baz</p>
					</div>
				:
					[]
			}
		</div>
	);
}

prom candy posted:

Multi-line ternaries in JSX seem to be pretty common because there's no other real way to do if/else in that context. They are usually an indicator that you need to break your component into smaller components, but not always. Also that indenting above is outrageous, I don't normally care about that kind of thing but I should be able to have two code panels open side by side on a 1080p monitor and not have to side-scroll any code.

prom candy posted:

Multi-line ternaries in JSX seem to be pretty common because there's no other real way to do if/else in that context. They are usually an indicator that you need to break your component into smaller components, but not always. Also that indenting above is outrageous, I don't normally care about that kind of thing but I should be able to have two code panels open side by side on a 1080p monitor and not have to side-scroll any code.

HaB posted:

I didn't mention the indenting because I chalked it up to forums formatting instead of his own because lol who uses an 8 space indent?

Capri Sun Tzu posted:

This almost looks like ascii art

Love Stole the Day posted:

I want to apologize to everyone reading this thread right now for starting this ternary discussion. I was only trying to help!

IAmKale posted:

Does VueJS have a concept of a "service"? I'm trying to figure out how to initialize a singleton class to wrap an API and manage auth credentials and use it across multiple components and pages. If I just use a regular "import...from..." when I want to use the class of course it won't preserve state and I'll have to initialize it every time.

rohan posted:

React 16 introduced the <Fragment> tag, which goes some way to fixing this -- it groups the nodes for return but doesn't render, so the resulting DOM tree doesn't have unnecessary parent divs.

(React 16.2 introduced <> as a shorthand notation, as well.)

Christ, this. I'm working with someone who I think has just discovered ternaries and the entire codebase is littered with things like:

geeves posted:

I'm fine with ternaries like that. I'd rather not have expressions inside props unless absolutely necessary. But that's just personal preference.

rohan posted:

There's no reason to declare a variable that's only ever used once, especially if it's only used in the render method.

Tei posted:

A exception to this is to abuse bool variables to deofuscate long IF conditions by giving semantics to parts of the conditions.

code:

var package_arrived = ( package.address_code == local.address_code);
var package_required_truck =  (package.weight > 80 );

if( package_arrived && package_required_truck ){
     truck.sendAndCollect(package);
}

vs

code:

if( ( package.address_code == local.address_code) && (package.weight > 80 ) ){
     truck.sendAndCollect(package);
}

SimonChris posted:

I don't know anything about VueJS, but the following works for preserving state in ES6 modules:

Tei posted:

A exception to this is to abuse bool variables to deofuscate long IF conditions by giving semantics to parts of the conditions.

code:

var package_arrived = ( package.address_code == local.address_code);
var package_required_truck =  (package.weight > 80 );

if( package_arrived && package_required_truck ){
     truck.sendAndCollect(package);
}

vs

code:

if( ( package.address_code == local.address_code) && (package.weight > 80 ) ){
     truck.sendAndCollect(package);
}

Tei posted:

A exception to this is to abuse bool variables to deofuscate long IF conditions by giving semantics to parts of the conditions.

code:

var package_arrived = ( package.address_code == local.address_code);
var package_required_truck =  (package.weight > 80 );

if( package_arrived && package_required_truck ){
     truck.sendAndCollect(package);
}

vs

code:

if( ( package.address_code == local.address_code) && (package.weight > 80 ) ){
     truck.sendAndCollect(package);
}

IAmKale posted:

Does VueJS have a concept of a "service"? I'm trying to figure out how to initialize a singleton class to wrap an API and manage auth credentials and use it across multiple components and pages. If I just use a regular "import...from..." when I want to use the class of course it won't preserve state and I'll have to initialize it every time.

I'm also incorporating Vuex and it's not yet obvious how best to expose the API class to a store module so I can make async requests in an action. Any tips?

Nolgthorn posted:

Nolgthorn posted:

I'm not sure what you mean in your question about actions. They give you access to context so you can use `commit` to trigger mutations within your actions to update the store. You can also cheat and import your store instance at the top of the file then just use that directly.

Nolgthorn posted:

code:

import Vue from 'vue';

import socket from './socket';
import router from './router';
import store from './store';

import App from './App.vue';

const vue = new Vue({
    el: '#app',
    store,
    router,
    render: h => h(App)
});

vue.$socket = socket;

Skandranon posted:

It's not that Vue doesn't support TS or it can't work with it, it's just the typing files supplied are a little rough. I've had no problems using it so far and am quite happy with how the two work together.

Check out vue-inject to get AngularJS like DI for services.

Check out vuex-typescript for getting strongly typed functions for your vuex store.

Check out vue-class-component for defining your components with decorators like in Angular.