Javascript 这样写，不知道为什么，总觉有点别扭

xxx?funA:funB

ele.Onclick= () => {
fn(xxx);
}

ele.Onclick= xxx ? funA : funB

没有缩进肯定别扭。

能用语法糖解决的问题都不是问题，"编译器"可以帮你优化掉的

function Condition1(){/*do sth when condition1*/}
function Condition2(){/*do sth when condition2*/}

xxx = "Condition1";
ele.Onclick= window[xxx];

动态类型嘛 习惯就好

你的直觉是对的，对一个 DOM 元素动态地绑定 /移除事件监听是很蠢的事情，编译器到底能不能优化到那一步我不知道，不过你的同事肯定是还没优化到那个地步。

如果你实在是有这么两个函数要重用，这个代码会写成：
```
el.Onclick= clickHandler

// clickHandler
if (xxx) {
funA()
} else {
funB()
}
```

写的什么鬼……

```JS
const fnA = () => {}
const fnB = () => {}
const handle = () => {
isA ? fnA() : fnB()
}

ele.addEventListener('click', handle)
```

@tinycold 这两种写法明显不等价。

@wenzhoou 我理解的「等价」是运行结果一样，不知道你说的「等价」是哪一层意思。

@wenzhoou 是的，当 click 发生的时候，xxx 判断的结果可能已经变了

函数在 js 属于第一类值，和 c 之类的有点不一样

Qt 信号槽，handler 就是可以变的，甚至两个的。

@pinews #12 也有可能需要保留那时的判断结果
单独存一个变量不如还是直接传函数。

不过如果这些个 funA funB 还会在其他地方用，我想还是存变量好，方便调试，知道是点击事件触发的。

@no1xsyzy 感谢，解答了我的疑惑

ele.onclick: (() => {
if(xxx) {
funA()
} else {
funB()
}
})

onclick 本质上是一个函数指针，直接指定函数指针或者在一个函数中指定，两者没有本质上的差别，但是有的时候给 onclick 赋值的时候要去掉之前的赋值，否则有可能 onclick 会指向多个函数

// handleClick
let handleClick;
if (field === 'a') {
handleClick = () => {
this.a(row);
};
} else if (field === 'b') {
handleClick = () => {
this.b(row);
};
}

理论上不建议 onclick，因为只能关联一个函数。应该是

target.addEventListener('click', () => {
xxx ? funA : funB;
});

你对 if-else 是不是有什么误解？两个条件分支是不假，但同时只会执行其中一条分支，只执行一条分支的话，哪里来的变来变去？

ok，就算变来变去，同一个元素的 onclick 被覆盖一下不行么，跟变量重新赋值一样，有什么不能接受的？

没问题啊，上面给 ternary 的，感觉还不如 if

不过确实 onclick 不如 addEventListener，逻辑可以在两个里面实现

不如试试在内部判断分流？

ele.Onclick= ()=>{
if(xxx) _funcA() else _funcB();
};

onclick 这里只被赋值了一次 也没有变来变去的啊

这样写不合理，函数有声明提升，建议把判断卸载函数里

小心，可能存漏

楼上一群说不合理，讲道理合不合理也要具体情况具体分析吧，这里 if 写里面和写外面明显不等价，而如果 if 的判断条件 xxx 是一个开销很大的函数调用，写外面甚至还算得上是一个小优化

if 里面写函数怪怪的，感觉哪里有问题

1) 函数在 JS 里是第一公民（ first class ），与变量可以被赋值传递。
2) onclick 是 DOM LEVEL 0 的事件机制，非常原始。如果开发现代应该建议直接上 DOM LEVEL 3 的事件机制 dom.addEventListener()

还没这样写过 onclick...总感觉这样写有点理解障碍?

前提：这个判断应该是个业务逻辑，业务逻辑是客观存在的，这个判断是难以避免的
所以这个判断不是以现在的写法，就是统一写在一个函数里面，在新的函数里面进行判断

那么就要分两种情况：
1. 这段代码是需要多次执行的，那些外面和写里面性能没区别
2. 这段代码是一次性执行的，那写在外面在性能上而言甚至优于写里面

至于 onClick 还是 addEventListener，看业务情况：
1. 需要兼容 ie 较低版本，或者这个 dom 只需要绑定一个 click 回调，onClick 无疑是最方便的，既不需要兼容也不需要在再次绑定时卸载事件
2. 多个点击回调，肯定用 addEventListener，不过就上面这段代码已经存在而言，应该不是这类情况

结论：目前业务逻辑下没啥问题，但是你改成自己喜欢的写法也没问题。只能说对业务和性能没啥产出，不过自己维护的代码让自己舒服这点很重要~

好久不写 onclick 了， 都是 addEventListener 或者 attachEvent