I was under a lot of pressure 😅 🤣

easier? maybe 😜

I was like huh Connor is on fire 🔥

@@ConnerArdman you wear really sweating from your butts. SMILES.. but you did so well

Do Angular

Thank you!

@@ConnerArdman k o klo

Thanks, glad you learned something from the video!

Haha in fairness I'm not sure I would come across quite as chill if I was talking to a stranger with a job on the line 😂

@@ConnerArdman still the way u pro coders think while solving any random problems given to u on the spot is just mind blowing for me.

Thank you!

Thanks! Glad you found it informative! 😊

Thanks!

Thanks! Clement really is good at following logic & finding errors in code he didn't write, definitely an under-appreciated interviewing skill haha

Yeah I spent some time after filming this trying to optimize it more out of curiosity (and it might be coming as a FrontendExpert problem 🤫😉) and it turned out to be a really interesting problem. I'm not sure there is actually a single "correct" solution since anything more performant than what I did in this interview would almost definitely be less readable, but it's an interesting discussion nevertheless.

@@ConnerArdman yeah it's a little difficult to say what the "correct" solution would be. Certainly using callbacks in your setState would do some good but it's really just putting a bandage on the issue, and only works in cases where you're not reading the state in the handleEvent function body. The proposed useEvent hook would also provide the same solution. Ultimately if you want to fix the redundant adding and removing of the event listener you'll have to rely on refs. I don't know if I'd say that it's less readable to do so either. With the recent React.StrictMode update people are needing to rely on certain ref/effect patterns to ensure their "run once" effects only run once(which only applies to development anyway). I think that unless React is planning to offer a built in solution, devs will start becoming more familiar with "initialized" refs, and even more complex methodologies like callback refs to handle problems like this(I would take on this particular problem with a combination of both probably 😉).

@@jcollins519 Indeed. A clean solution would be to use a ref with the callback using the "latest ref" pattern for the listener callback, and pass that into the event listeners; that way the listener always gets the latest state while the event listeners are only attached/detached once (in production). This is also how useEvent works somewhat. As an aside; StrictMode is only enabled in development mode. It is removed in production builds, so it's not going to double render. So it is not necessary to use refs to avoid double rendering; only if it becomes an issue during development; i.e. you're external network calls or doing heavy computation. But this is exactly why StrictMode is a useful tool to catch those issues, so that you see them and can act upon it. It's not really needed at the top-level of your app, but rather more useful to wrap about certain parts you think are important to optimize.

Thanks! I think anyone can get with practice, but yeah I’ve had a lot of practice explaining while coding at this point.

Absolutely. Hopefully they become more common over time 🤞

And many times interviewers ask garph/tree problems in the frontend interview 🤣

Vue (3 with script setup) is in every single aspect better than React. Well maybe besides job offers.

@@drizzletone9148 Theyre both tools for specific purposes and solve problems for a business. It's not an X > Y scenario. You either use one or you don't.

Svelte - compile time, no virtual dom

React sucks. There are many libraries/frameworks that are thousands of times better, such as Vue and Svelte. Thinking React is the best web development tool is like thinking Mcdonalds makes the best food or Windows is the best operating system. Facebook sucks even more than React.

Thanks! And you’ll get there soon, it wasn’t that long ago that I was feeling the same way watching this type of video 😀

Coming soon 👀

it's all staged bro 😂

This exercise is very close to real day to day dev work so with project experience it should be easier. At least it isn't arbitrary leet code questions on a white board.

What if you input the same letter twice?

@@vgerov1 save letter as reference type should solve it. array with one item or object with one property.

@@pEeLL00 That will work, thanks. The whole solution will cause an extra render, though, which might be a problem in itself.

Awesome! Good luck learning JS 😊

Yeah I totally agree that you need to study beyond just what you might use in "normal" everyday React projects. Oftentimes those less-used hooks are a good way to gauge the difference between someone who has used React and someone who has really studied it / knows it fairly deeply. And shameless plug, we do have videos on these hooks (useMemo, useContext, useRef, useImperativeHandle, etc.) as well as some hook-specific practice problems on FrontendExpert :)

Thanks!

You could also "revert" the dependency by creating a custom hook that listens to every key press event, stores the pressed key info, and returns it. Then in the main component have a useEffect that runs whenever the custom hook returns a new value.

Yeah I think useReducer is the best way to solve this if it is a problem you are concerned about. The custom hook you described could probably work also, although I'm not sure that's much better honestly, just because it creates a lot of extra code.

More coming soon 👀

Yeah I think this is definitely the cleanest way to solve that useEffect problem, honestly not something I even considered in the moment.

Interested in collaborating?

Thanks! It really depends (I know, that's not a very satisfying answer lol). In general, I wouldn't think of problems as having a direct mapping to a level, but rather there are different expectations for different levels in how candidates will solve the problem. I'd say this is probably in the slightly harder realm of problems, mostly due to it's length and ambiguity. I don't think I'd expect an entry level developer to completely solve this in less than 45 minutes without hints, but it might still be a good question to ask them to see how they approach it and to give them room to really excel if they can complete it. On the other hand, I'd probably expect a more senior developer with substantial React experience could probably get through the problem, and they might excel further by bringing up additional concerns such as accessibility or how this could have been improved with server-side rendering.

@@ConnerArdman Thanks for the answer, I asked because I have been working with react professionally for 6 months now, and I was looking to change my job but I still have no idea what level my current react knowledge is at. So this answer gives me everything I was looking for. Thank you a lot. Keep up the great work!

Thanks! Unfortunately I don't think I actually have these files saved anymore 😔 I'll make sure to post the code for future videos. We do have a similar version of this problem coming to FrontendExpert soon though 😉

I don't necessarily think it's a very big problem since the browser can add/remove event listeners so quickly, but the solution is essentially just to use useReducer, which would naturally remove the dependencies from the useEffect (because React automatically passes them to the reducer function which would handle the logic outside of the useEffect). I'm not planning on making a video on it, but we did add a similar problem to FrontendExpert with useReducer as one of the solutions 😉

You got it, just keep working at it and you'll be there before you know it 👊

Glad you enjoyed it, good luck doing it yourself! 😊

Thanks, glad you enjoyed it! 🙂 ** Insert subtle plug for frontend interview prep course linked in description **

That's just shifting what triggers the re-render. useContext will trigger re-renders where it's used.

Thanks!

Spread and Splice is a waste because we're using react state, it's better to use slice() because modifying the original string is bad practice in general for "immutable data handling". The ideal way is setCurrentGuess(prev => prev.slice(0, -1));

Yeah this is because the AlgoExpert servers don't expect requests from non-algoexpert domains, so the browser blocks the request for security reasons. Technically you can disable cors in most browsers with some extensions, and that would work (although I wouldn't necessarily recommend doing that, and if you do make sure to re-enable it when you're done). Alternatively, if you own FrontendExpert, we released a version of this as a problem over there today with the same API (and requests to it will work from the FrontendExpert workspace).

I would actually disagree with the idea that using fetch in useEffect is an anti-pattern. Event handlers should usually be the first choice where they make sense, but not all data fetching happens in response to an event. In these scenarios, there really isn't another good place to do it without needing another framework on top of React. In this case, the data needs to be fetched when the component is first mounting. Since a component mounting is a React concept, there isn't going to be an event that directly maps to it and allows us to easily rerender the component when the fetch completes. If this were a production webpage, then I would probably want the solution to be sent down with the initial page load, likely via server-side rendering. That said, for this problem in an interview context I think useEffect was the correct choice (although _maybe_ it would be slightly cleaner to add a cleanup to that effect to cancel if the component unmounts, but that is mostly a non-issue since the component cannot unmount in this simple page). For reference, here is the page of the beta docs describing fetching data with useEffect: beta.reactjs.org/learn/synchronizing-with-effects#fetching-data

In case there is confusion here, Clement is the interviewer and I am the interviewee in this one. But to answer your question, Clement learned to code in 2016 at a bootcamp and got his first full time job in 2017, so he has ~5-6 years of coding experience. I first learned frontend development in college in 2016, then I learned React at a Facebook internship in 2018. So I have about the same years of experience as him coding in JS/React, but with just under 2 years of that being time spent working full time.

@@ConnerArdman So what if I just started learning React, any suggestions how should I approach? Any bootcamps? Your help is much appreciated. Please do reply.

@@piyushchopade7878 Learn some basic stuff like useState, useEffect and components. Get your hands dirty. Start making projects. Start with mini projects(for example minig games like Tic Tac toe), portfolio websites or trying to clone websites you like(for example Netflix, Spotify etc.). (I assume u have basic knowledge of JS)

Don't do that, this is definitely not a level you need to be at to get your first job. This would have taken me at least twice as long to do (if I could even do it) when I was first learning and applying to jobs 😊

Glad I could help 😂

Probably not. I don’t know it very well tbh

This is Code Sandbox, so it's whatever their default font is.

This is true in a lot of other languages, but JavaScript's Math.random() doesn't accept any parameters unfortunately.

Yeah if he asked me to handle that, that's pretty much what I would have done. I'm not sure of the exact rules actual Wordle uses, but it should just be some basic string manipulation.

Just Dive in its man I swear on me you won't regret it it's like putting Legos together typing it out didn't sound as fun as it did in my head but react is lit and its beginner friendly

5 years of experience is no beginner xd

Yeah eventually I'll probably make a video around how I prepared for interviews. I just need to think of a good way to frame it, because honestly I don't think I did anything particularly unique.

@@ConnerArdman then say that in the video! cuz in reality there's no special shortcut u can do.

This was a long time ago, so I don't have it anymore. That said, we released a question on FrontendExpert for free based on this here: www.algoexpert.io/frontend/coding-questions/wordle The code is very similar, just cleaned up.

@@ConnerArdman Thanks btw I solved it yesterday. It was a great question.

I'm not sure I follow what you mean by not using "open arrays" without state or the part about polyfills. If you're referring to the tiles array, there was definitely a cleaner way to do that, but I don't think the solution I gave was incorrect in any way, especially for a short interview. As for the function and block scoped logic, I'm not really sure what you're referencing here either. The only code scoped outside of functions were constants, which is a generally accepted practice. I agree about == vs ===, but there is a special case with == null. When you do val == null, it essentially is also checking for undefined. Some people prefer this while others don't, but it certainly is not incorrect. For instance, at Facebook my team (and I believe most if not all teams) preferred == for the null case. For switch vs if/else blocks, I wouldn't fully agree with the idea that anything > 2 cases needs to be a switch. If the conditions are more complex than checking a single value, then switch cases can get complicated in my opinion, since they are meant to switch on possible cases for a single value. That said, my logic around the event.key probably could have been more readable. As for for loops, I've used a few traditional for loops in production code but mostly agree that ES6 functions should be used instead in most cases. In the case of the tiles loop, it probably would have been better to make sure the guess string was 5 characters and use map as Clement suggested, but in the timed interview I just had to do what came first/most naturally to me.

There is nothing glaring bad about what he is doing for this type of interview scenario. Arrays are perfectly fine to use for operations that are needed for display logic or render logic, these aren't state, they need to be "computed" each paint. An improvement would be using useCallback to memoize handlers etc. Also memozing components that have heavy business logic needed in the renderer.

Get better hater

This is a really good question. React effects should always clean up after themselves. Each time the effect runs, a new event listener is created. But if the hook runs twice, we don't want two event listeners, so we need to remove the old one on cleanup before creating a new one. Additionally, if the component unmounts, we want to delete the event listeners so we don't have a bunch of useless event listeners when the user has navigated away from the portion of the application that needs them.

@@ConnerArdman thanks bud!

@@ConnerArdman Wow thanks for the really good explanation!