Hello guys 
So, here’s my solution :
function findElement(arr, func) {
arr.filter(func) ? arr.filter(func)[0] : undefined
}
findElement([1, 2, 3, 4], num => num % 2 === 0);
// It passes the first one, but on second call,
// test doesn't pass, saying "Should return 8".
findElement([1, 3, 5, 8, 9, 10], num => num % 2 === 0)
What am I missing ? Because if I log, the answer is good 
your function doesn’t have a return statement
other than that I would need you to provide the challenge link to know what’s wrong
You forgot a return statement.
Also, filter always returns an array, and empty arrays [] are truthy, so the ternary operator is pointless.
Also, I suggest you check out the find Array method:
Damned! Indeed @ILM , I totally forgot the return statement. I thought that was “? (return) X : (return) Y” hihi
Pardon my memory, thank you
And indeed, I got misdirected by the test saying it’s good.
As
arr.filter(func)[0]
return automatically undefined, ternary operator is useless indeed.
Thanks.
ps : yeah I saw the find in the solution, great 
But I wanted to succed with my filter solution 
Here is the new solution then 
function findElement(arr, func) {
return arr.filter(func).length > 0 ? arr.filter(func)[0] : undefined
}
Thank you to both of you
what value has this if the length is 0?
do you really need to iterate twice over the array?
It’s undefined indeed 
Okay, let me make a better one :
const findElement = (arr, func) => arr.filter(func)[0]
@GregFR You solved the problem and that’s great! I’m not trying to get you down, but there’s always room for improvement so I want to point some things out.
Filter creates a new array in memory with all the values that return a truthy value when passed into func. In a worst-case scenario, let’s say you have an array made up of a million elements, and every element is the string “foo”. Let’s say that the func callback is x => x === 'foo'. When you pass those to filter, it’s going to make a new million-item-long array of “foo” in memory. This creates a lot of waste, especially when the element has already been found at index 0, there was no need to check the rest of the 999,999 elements.
Secondly, semantically when I see filter in a piece of code, I expect that the filtered array has a purpose as to be an array. In this case it does not, all we care about is a single element.
So the reason I suggested the find method above was not only because it’s simpler to read and understand, it’s also more efficient (it short-circuits once it has found an element). If not the find method, then a for loop could also be written to short-circuit.
I understand if you’ve just learned about the filter method and want to get used to using it, but I just don’t think it’s the right tool for the job in this situation.
Thank you for your explanation Colinthornton !!
I totally agree with you. I was aware already that filter goes through the entire array, thanks for a project I made (I was checking if filter.length was true, but I replaced with arr.some, awesome method also), and here I got mislead indeed with the findElement having just an tiny array so I went with filter
I understand that find does the job perfectly here, thank you for all your information. Very interesting to read that again (until it fixes itself in my head ^^)
No problem. And I want to reiterate, code that works, no matter how efficient or inefficient, is more valuable than code that doesn’t work.