Video guide
28:02 · 10 May 2024
React Live Coding Interview: Build a Travel Cost Calculator
Chapters 5 sections
Key concepts in this video:
- 01
1. Ask Questions Before You Type
Bogdan did not open the editor first. He walked the mockup and asked: does the starting point need validation? Do the vehicle options come from the API? Should the total refetch every time a destination changes? Is submit in scope?
Each answer cut scope: no validation, mock the API, refetch on every change, submit is out. Five minutes of questions is cheaper than twenty minutes of building the wrong thing. Interviewers score the questions too.
requirementsinterview technique - 02
2. Sketch the State Before the Components
Before code: a quick sketch of the component structure and the state. A starting point string. A destination array. The vehicle type options. The expense name. The total amount.
Destinations are an array of objects, not strings — each needs a unique id, because React needs a stable key when rendering lists and you will add and remove entries. Modeling the shape up front saves the mid-interview scramble.
Reactstate designdata modeling - 03
3. Essential State vs Derived State
Essential state changes independently — you cannot compute it from other state. Derived state is calculated from other variables. Example from real work: in a checkout cart, the items are essential; the total and the tax are derived.
Here the total amount looks derived — but it is computed on the backend, not the client, so on the client it is essential state that arrives over the network. Getting this classification right decides how much state you store and how many bugs you avoid.
derived stateReactstate management - 04
4. Brute Force the Markup, Then Add Behavior
The build order: write the whole static JSX first — labels, inputs, the select with hardcoded options, the button, the total — with no components and no CSS. Then wire state in.
This is deliberate. Splitting into components while the requirements are still moving wastes interview time. Get the skeleton on screen, confirm it matches the mockup, then make it dynamic. Small accessibility touches for free: htmlFor on labels, names on inputs.
Detail that saves you a bug: give the button an explicit type of button. If the markup ever gets wrapped in a form, a default submit type triggers weird behavior.
JSXHTMLaccessibility - 05
5. Controlled Inputs: value Plus onChange
Every input gets binded to state: value from the state variable, an onChange handler that calls the setter with event.target.value. That is a controlled component — the standard React pattern for forms.
Bogdan chose independent controlled fields over a single HTML form element. With separate fields, reading and validating values on submit is slightly easier than digging them out of the form target. Then verify in the browser with React DevTools: type, watch the state update. Always debug with the debugger, not with hope.
controlled componentsformsReact - 06
6. The Dynamic Destination List: map, Keys, and IDs
The destinations render with a map over the list. Each row needs a key — that is why every destination carries an id. For the interview, Math.random stringified is good enough for ids, with the disclaimer said out loud: never in production.
In production: a UUID, or create the record on the backend so the id is consistent with what the server has. Adding a destination is a state transition — spread the old list, append a new object with a fresh id and an empty value.
Declare the TypeScript interface for the destination early. Type inference then flows through the map and the handlers and makes everything easier.
React keysUUIDTypeScriptlists - 07
7. Updating One Item in a List Without Mutating
Changing one destination's value means: find its index by id, build a new destination object, copy the list, replace the item at that index, set the new list. Never mutate the existing array — React state updates must be immutable.
Bogdan flagged the trade-off himself: this array search is inefficient. A hash map keyed by id makes updates cheaper but rendering clumsier, because you iterate object keys. For a form this size the array wins; knowing the alternative is what the interviewer is listening for.
immutabilitystate updatesdata structures - 08
8. Mocking API Calls with the Promise Constructor
No real backend in the interview, so the fetches are faked properly: an async function that returns a new Promise resolving with the data. That mimics real network behavior instead of just returning a value — the component code stays identical to production.
Two mocks: getVehicleTypes resolving with value-label pairs, and calculateTotalAmount resolving with a number. Each option keeps a separate value and label — labels are for humans and get translated, values stay universal.
Promiseasync/awaitAPI mocking - 09
9. useEffect for Fetching — and Why Fewer Effects Is Better
The vehicle types load in a useEffect on mount. The expense name recomputes in an effect when the starting point or destinations change. The total amount refetches in a third effect. It works. It is also the part to improve.
The interviewer asked the drawback directly: effects run after render and then trigger another render, so every effect is extra re-renders. The fix is to move state transitions into the event handlers that caused them — set the expense name inside onChange, not in an effect watching the inputs.
For the data fetching, useQuery replaces the effect entirely and gives you loading and error state for free, like a real network client should. This component can be written with zero effects. Saying that unprompted is a senior signal.
useEffectuseQueryre-rendersReact - 10
10. The Follow-Up Questions: Testing and Styling
How would you test this? First extract components — everything in one file is untestable. Unit test each field component that carries logic, then an end-to-end test of the whole form with Cypress. For the API integration, mock the calls with Cypress fixtures.
Styling: CSS-in-JS via styled-components, because scoping styles to components and driving styles from JavaScript values — say, coloring a field on validation state — is easy. Plain CSS works too once styles are scoped to components.
Also asked: why Vite over webpack? Vite is faster and easier to set up, and that is where the ecosystem has moved. Short answer, no essay.
CypresstestingCSS-in-JSVite - 11
11. Why Live Coding Is the Skill of 2025: Take-Home Inflation
AI broke the take-home task. With GPT and Cursor, backend devs submit decent frontend tasks and vice versa. Where a company used to get three submissions, they now get twenty. The signal is gone.
Take-homes are high effort, low value. Companies say two hours; delivering something that actually advances you takes closer to twenty — deployment, tests, a README. Then a reviewer spends a minute on it and rejects on a whim. The commitment is asymmetric and the candidate is the losing side.
And you will live code anyway: pass the take-home and the next stage is extend this code live. If AI wrote it and you cannot explain it, you are in trouble. The few developers who can actually live code stand out automatically — and the feedback loop is days faster. You can do ten live interviews in the week one take-home consumes.
take-home tasksAI toolsinterview strategy - 12
12. Why Developers Go Blank: Four Real Reasons
The same four patterns show up in every developer who freezes in a live coding interview:
- The LeetCode disillusion. Grinding LeetCode for months burns you out, and the interview problem is one you never touched anyway. It is one of the most inefficient ways to get good at live coding.
- Tooling dependency. Interview editors often have no autocomplete, no AI, no Google. If you have never coded from the top of your head, that is a new world — and it says nothing about your ability.
- Framework abstractions. You never write a for loop because you use map and reduce; you never construct a Promise because fetch hands you one. When the abstraction is gone, it feels like you know nothing. It is just unpracticed territory.
- Past trauma. One brutal interview and people refuse the next one, even from a dream company. The elitism in tech amplifies it. The result: developers who can code but cannot program. That is fixable.
LeetCodefundamentalsinterview psychology - 13
13. The Fix: Make Fundamentals Second Nature
The exercise: open a plain notepad and write a program that sums an array with a for loop. No IDE, no autocomplete, no framework. Code is just text that a compiler interprets — going to that extreme strips the dependency and shows you the fundamentals were always simple.
Then think in first principles: every time you write a map or a reduce, ask how you would write it with a for loop, with a while loop, and recursively. Those three questions cover almost everything that matters about that piece of code.
Complexity is only an aggregate of simplicity. Every problem in isolation is small; interviews feel hard because the small things arrive together. Master each atom — loops, recursion, basic iteration — and the higher level gets fast on its own.
fundamentalsfor loopsrecursionfirst principles - 14
14. Pick Your Battles, Learn Patterns, Know Your Keyboard
Do not train dynamic programming unless you are interviewing at Google — and even there, only a small fraction of interviews contain it. Ninety-nine percent of companies will never ask it. Get fully confident at iteration first — confident meaning you can write it in a plain text document — then two pointers and sliding window, then graphs if you ever actually need them.
Focus on patterns, not problems. Solving one company's exact question teaches you nothing transferable. After every problem, name the pattern you used and apply it to three or five more until it is part of your mental toolset.
Bonus: touch typing. In the red zone of an interview, every mechanical mistake compounds toward paralysis. Fifteen to thirty minutes of typing practice a day removes a whole class of failure. Fundamentals plus typing plus patterns adds up to a performance that surprises even you.
algorithm patternstouch typinginterview prep
Transcript
Hi everyone. Today we are here with Bogdan and we're going to go to a live coding interview, React interview. This is a real coding challenge that one some of our menes uh got and we decided to solve it today with you. Um, Bogdan, are you ready? Yes. Awesome. Let's go. Then um I sent you a link with a um mock up and let's go through it. This is what you are going to build today. This is a travel cost calculator. Um as you can see, it's a it's a web form.
Uh we have a starting point, a destination. This data will come from an API, but you're going to have to build the input forms. And based on that and the vehicle type that the user is choosing, we're going to have a calculation going on that's the total amount. The submit functionality that you see there with this button submit, that's out of scope for today. But there's a catch, right? When you click on the button add additional destinations, right? You see it add additional destination.
Another um destination form should be added, okay? Okay. Uh so far so good? Yes, I do want to ask a couple of questions before we get started. Okay, so correct me if I'm wrong here. We have a starting point, the user will edit this so they type Berlin or whatever. Should we add any validation to this input field for the scope of the exercise? We could, but uh again, we don't have a lot of time here. No no validation needed so far.
Okay. And then they add the destination, and if they click on add additional destination, they can also add more destination fields. Yes. Perfect. And we'll have the vehicle drop down and these options come from the API? Yes, you will have to mock this. Just you know, we're going to add the ones you see here, car, train, plane. Mhm. Uh perfect. And then the expense name is calculated from IC based on the starting point and the hypothetical destinations, but the users can edit it.
And then I see is the amount which is the one you mentioned. We need to fetch from the API. Should we fetch this every time they type or they change the destination? Yeah, I want you to mimic the fetching again. We're not going to query the API this time. So, maybe you can mock it using um, yeah, some JavaScript function. So, I would assume the amount has to be refreshed every time somebody adds a new destination or they change, for example, the starting point. Is that right? Yes. Okay, and the summit it's all this up. Okay. Perfect. So, I'm just going to go ahead and sketch it real quick before I go in type, um, the component structure, pair to identify the state. So, it's pretty obvious that we'll have some sort of starting point state. So, we have a starting point input, we're going to add state because users can modify that. Um, then we have a destination array. So, we definitely will have a destination array that we need to submit. And I would assume why are you going for an array? Uh, because this is a list of destinations and we'll be able to add more destinations or remove. Mhm. I would assume. When it comes to the destination object, I would say because we I mean we could store this as strings, but that would limit us. So, would assume we're going to have to create an object here and I would say one of them would be the ID of the destination. And the other one would be like another value. So, I'm going to model them like this, so let's say this is Berlin. And for the purpose of the exercise, maybe we just keep this to the lowercase value. But this should be a unique ID. Mhm. Yeah. Just because we're going to we're going to need a key value for for React when they and all that. So, when people add a new destination, there will be here a state transition. And we add a new destination with with probably a random ID, an empty value. And then here we're going to have state, which is basically the uh vehicle type options. Mhm. Okay. And then this would be just another input field. I will call it expense name and we can use an effect to whenever somebody um changes it.
it. They they can either change it manually or have an effect or like whenever they change the other parts of the state, we update this version. Okay, and then we also recalculate the amount with the fake uh with the fake call. Perfect. So, this would be all the essential state I would say. I don't see any derived state, um, because this is coming from the uh back end. There's definitely no derived state here. Everything I see it's essential state because all the state had like it's pretty much independent. This amount looks like derived state because it feels like we can compute it from the other values, but we're not doing that on the client, we're sending things to the back end and then getting it back. Yeah, we only have essential state here. Okay, cool. So, should I uh I think I'm ready to switch over to the code and we can start trying to implement this. Uh, sounds good. Just before we do that, I mean, you talked about essential state and derived state. You know, what is essential state for you? What is derived state? Uh, what's the difference? Uh, so essential state state that um basically it changes independently and you cannot really derive its value from the other state variables. and derived state it's basically state calculated based on other state variables. Just to give you an example from my past work, whenever you have a checkout cart, you could assume that the essential state the items in the cart, which can only change if the user does something. And the derived state would be for example, the total amount or the tax that you calculate based on the items. Awesome. That then let's go and uh let's uh I want to see you building this thing. Uh, do you have your VS code everything set up? Perfect. Let me share. I do have a Vite starting point with React in my VS code. I see your VS code, yeah. You've got a appTSX.
webpack What's the difference if any? Um Vte is just faster and easier to set up these days and most people are moving to Vte. I love webpack, I worked with webpack before. It's just becoming a bit slower. So, you know, these pretty much everybody goes with Vte because it's it's a lot faster. Cool, then let's go with Vte. Okay, now, I'm not going to focus on any CSS in the beginning, I'm just going to go ahead and write um the bare structure kind of of this whole thing. Let me just, and by the way, should I disable copilot? I I do work with copilot most of the times. What do you prefer? For this interview, let's say you can use copilot. Yeah, so in our company, we do use copilot, so yeah, you are allowed to use copilot. I'm going to start with the uh with the structure. I'm just going to code uh the HTML markdown, the JSX for this. And I will not focus on making individual components at this point. Yeah, it's just kind of the brute force approach to this interface. Which basically means just let's get the markdown rolling and then I add the functionality with the state. So, um we have just to start with, our first group would be a label with um what do we have there? That's a starting point. Starting point and then we have our input field and let's see what does the input has, has a placeholder, let's say. Place holder that's Berlin and just to make this pretty well to make this super accessible we can say HTML4 and then we can add the name to this. So the name would be uh this is the starting point, perfect, and I'll call this starting point. Now, this would be our first input and we basically have another one that's our first destination. So that would be our destination 01, let's say. Going to call that destination. And the placeholder would be London and this would be destination 01. Perfect. So then there's the
add addition destinations button. So I'm going to add that one over here. And this is a plus additional destination. Okay, add an addition destination. And then we have our drop down and then the expense name. So basically, we're going to have a select and we're going to have a bunch of options. I will high code everything for now and then we kind of go in and make everything dynamic. Okay, I'm just using co-pilot suggestions, but we could use car plane.
And then we go over with our last one, which would be that div. And then we have our expense name, Berlin and Paris, cool. So we have our label, uh expense name, so as you see copilot goes goes ahead and does a lot of for me, but expense name and then this will be uh no no placeholder, you know, just call this expense name. Perfect. I'm going to format this. Format this document. And the last part it's the total amount in the submit button.
So I'm going to put all this together also in a div. Okay, that's closing tag. That'll be our total amount and that will be whatever. 01 uh dollars. And we're going to have a button that it's a submit button. I'm going to go ahead and just add a type here and make this a button. Because if it's a type submit, sometimes you get some weird behaviors. So this is just basically the honest take rid of all this stuff.
It's basically the simple HTML markdown. How does this looks like here? Okay, looks nice. Good starting point. Okay, I'm going to add a travel cost calculation just for the sake of uh being uh perfect travel expenses calculator. Copilot is pretty impressive. So now it's when things get a bit more interesting. I'm not going to care about the CSS at all, okay? We just want the functionality. Um, so let's start with a simple stage.
And I'm going to hand let state here. We could have put all this in a form and then manage the form values, but I'll choose independent inputs because it's just kind of easier to get started with starting point. You choose independent fields, how are you planning to manage the submission, right? Because when you choose a an HTML form, right kind of the submit button is going to grab everything that's in the form, right? Um, how are you going to do it?
So I'll basically have an on click on the button and then store all these values in state. If I were to have a form, I could access all the values at once by doing form. um like even the target. form and then get all the values. But it will still not be super straightforward to get those values and validate them, it's it's likely easier if they are separated. Mhm. Awesome. So, this is our starting point and we have the state starting point and that will be a use state which I'll say perfect.
So that's our first one and then we said we have our destination list I I would call it, just to be super explicit. And I'll call it set destination list, that would be the initial value will be an an array with one destination. Um, so we're going to do this. And here we mentioned we're going to have an ID. Now this is where it gets tricky, how do we generate an ID? We could actually do string of math. random.
Um, I do not recommend this in production, but it's good enough to get started. How would you do it? I don't want the implementation, but how would you do it in a production environment? probably use something like a UUID for a much safer ID. Kind of the standard solution. Yeah, and I know some use cases where people actually they make a request to the back end and created in the back end, so then you have data integrity.
But you ID should be fine. So you don't do it only client side, right? You you create the back and you make sure that you're actually consistent with what you have in the back end. Yes, um and then I would add the add destination, this would be an event handler, we can handle the the state transitions afterwards. but let's go for the for this one here. We mentioned this will be fetched over the network.
So I'm just going to fake that. I will create an sync function um and call this get um vehicle vehicle types. And um let's say it has no parameters. And it just returns an array of value and label for for this types. We can fake that, we can just do return a new promise, cuz we want to kind of comply with the sync function. Yeah, you want to mimic the API fetching behavior, right? Exactly. So this will resolve with um perfect.
Yeah, that's. I would probably also need a value here, but we will use the label like this would be the actual the label which should be normally translated and whatnot. So what do we want to do here? Um we do have our vehicle type list and we want to set that and in the beginning it's an empty array. Um and then we just want to do for now we would use use effect for this. That's better ways than use effect nowadays.
Go with this. Could you just mention some of those better ways? Yes, if you want to avoid effects, you can look into use query, which avoids using effects and it gives you the loading and error state uh for this vehicle types. Because normally I would have a loading state that I need to display. So I'm going to go with this. Yeah. You should have to handle all the network uh use cases, right? Error loading, uh just like a network client, right? And and that's what query does for you.
But for now let's just roll with uh use effect, you know, maybe that would be for a second iteration on this. Mhm. Um Now, I have a type error because I did not declare the type of these vehicle types, so let me just declare it interface vehicle type. And then this should return a promise. of vehicle types. Perfect. And now I should have no type error. It's perfect. So that's the vehicle type. And then we finally have the expense name, um, which would be again just a string. So that will be constant expense name and then set expense name to that state. Okay. And then we have the amount, which is another state because it's get we get that from from the back end. So that would be also constant, total amount and we start with zero and you mention I need to fake that one, too. So I'll just go ahead and do like in a sync function, perfect that takes all that in, and then it returns a promise with a number and it returns basically this. But we can also do this a math. random by a 1000. Perfect. So that's our wear amount function. I'm going to zoom out so you can see it. Perfect. And so now, yeah. Now, let's try to connect these two things. So we have the markdown, um the first thing I want to do is to connect the starting point and this should be rather straightforward. We can just say that the value of this is equal to the starting point, and we can also say that on change, then we will actually trigger, so this will get an event and then on that change, we want to do set the starting point to even target that value. Oh, pilot. It's amazing. Yep, let me see if this worked out, Berlin. Let me see if I can inspect this and debug it with my debugger. That's always the best idea. We have our app, perfect, and that's a state. So, ideally, if I type something else, works great. Perfect. So, I guess you can see this in here. Awesome. Then it's going to be a bit of busy work making the Oh, no. This is when it gets interesting. So we have the old whole destinations. Wow. Okay, that's go pilot. But I'm going to do it myself just for the for the sake of it.
So we have our destination list, perfect, and we want to map over that. So that's our map function, and I close this. Perfect, and we want to return for each one of them, we want to return this. And now I'm just going to go ahead and do some smart replacing. We know that each destination has a probably should an ID and again a name and I'm going to declare here the interface. Perfect. ID and name. Hm and then make this perfect and provide this as a destination list. Just because it's going to make all the type inference. Type inference will make our fingers here. So, we have destination here. Um and we know it has an ID. So all of a sudden, we could actually add an ID or a name here. So the name would be destination, we can use string interpolation here and do destination minus dollar sign. And then destination.id, for example. Um and the value, uh okay, so we have our destination. Yeah, the value will just be destination. value. Okay, that name, that's what we use. Oh, I understand now why I had value here because we actually need the value. Because this is kind of an input field, so let me make this a value. That's Uh-huh. Oh. Be careful. I'm getting ahead of myself. Be careful. That'll be a value and a destiny. That's type thing and I think the type in yes, that's a value. Yeah, perfect. Okay. So, that would be it. We can actually use the this also as the label for. Perfect. So, that's fairly semantic. Let me format the code. What's missing here? The change. So, whenever I change the value here, I should change the specific destination. Um and that's when it gets
it'll be a bit more tricky because I need to find that value and recompute the state. The easiest part, the easiest way would be to have a new component and encapsulate that there, but I will do it here. I'll just call this onchange. And then, perfect, we have the change event. And here, what we want to do is to find the destination by ID and then um create kind of the new destination and then update that. So, this is where it gets tricky because we use the list for this. We could use a hash map, which makes things easier to update, but a bit harder to render because we need to do like object keys and render them. Um, I'm going to go ahead with the uh implementation of the array, but we can maybe discuss at the end about the hash map. I don't know how we're doing on time. How how much time do you think I still have? Um, I'll say at least 15 minutes, at least. Okay, 15 minutes. Not not a lot. Perfect. So I'm just going to go ahead and say that this is my destination. Perfect. That's the destination index. And then I could either um let's create a new destination, which is basically the ID, and then we set destination list to the new destination list. Um, so this would be the state update. Wait, one second. So this is our destination list, but in the new destination at the index, we set it. So, as you see, basically find that destination, create a new one with a new value, and then I duplicate the list and replace in that list that new destination and then update the state, very inefficient. We could do we can change this if we use a hash map. But for now, I will roll with uh with this implementation and just provide this to the onchange. So, onchange. Okay, let's test it out. So, going to go over here and click on destination, I'll click on London, and I would expect this to be London. Um, nice. It's working. It's working. There you go. Now, let's do this button. So, we have that button, and basically, what do we want to do?
on change. Let me just add it here. State transition here, we want to push, like add a new destination. So basically we want to set the destination list to whatever the destination list was. Let me go in. Plus the ID and the new value, or string. Yeah, this looks pretty cool. Copilot did have it for me, but I could have just typed it out. And now we go to that button we had and add that on click. Yes, and I'm going to add a type button here just to make sure that if this will be wrapped in a form, we we don't get some weird behavior by submitting the form.
Let's see. So, I click on add destination and I'm going to say Madrid and this would be Berlin. So, we have Berlin and here we have Madrid and London. Yeah, it looks pretty pretty decent. I look this these IDs are very annoying. Cool. Okay. Let me go back and see how we're doing. So, we're basically all the way here. We we've done all that. We could delete destinations if we wanted to, just by finding it and removing it in the array.
But don't move forward with the vehicle type and an expense name and the amount. Okay, so in the vehicle type, we just want to transform this into a uh vehicle type. map, vehicle type. map, perfect. Very good. And and we have some logic here. And here I will have an ups with that key. We need keys for performance. Um and I do think we need a value too because that's how you know. And I'm going to use the the label as a value, but normally there should be a value.
Because the label is something that humans can read, it can be in different languages, but the value should be universal. So maybe you clean the other options. Nice. Perfect. And now let's see, if I go over and what's happening here? I click truck us. Okay, now let's connect it to state, can go on change. And just say we have an event. And it basically says, set the vehicle type. Oh, we don't have a state for that. So that's the one we missed. Constant, that's a field itself. Yeah, selected vehicle type. So, two things. We need a setter to the event .target.value and we need the value of this to also be binded. So, the value should be equal to the selected vehicle type. Let me see if it works and then I explain my choices. So we go over to app and there's nothing in there and I select truck. And we have truck here. Mhm. Yeah. Um, last but not least, we have the expense name and the amount. I move forward and then maybe we can perfect. So the expense name would be Yeah, we can do that with an effect, whenever we change the starting point or the destination list, then this could actually also set the expense name to Yeah, to starting point. Actually, in our requirements, we had starting point minus. Yeah. And then we were joining those with a minus, I think space minus space. Maybe add some spaces between the minus. Yes. Perfect. So basically, if I type here Berlin, Wait a second, set expense name. Oh, but we need to link the values. So expense name value value should be the expense name. Perfect. So I have Berlin. Oh, you see, there's a bit of an error there. Um, if I type there London and then Madrid, this should kind of work. Yeah, it kind of works. Can it Oh, okay, we can add the display. Yeah, I need some CSS, but let's say this is be born here in Germany and it's going to work out. So, and finally, I mean, I should have also the ability to change this. So we need an on change here to do the same. And then for the total amount, we could use another effect, um, which basically it's
calling the calculate total amount. resolving that. We have destination list. What is here? Destination list, it's an array of destinations. Okay, so I should have no type error. This is getting a bit longer. And then set the total amount to it. I think right now if I go ahead and type Berlin, Okay, let me refresh. Berlin. Oh, the total amount doesn't really change. Did I high code the the total amount in the?
Give me a sec. Now, so we resolve that. Give me a sec. So, what do we do here? We set the total amount to the total amount. Oh, it's not dynamic, so should have here. The total amount. So if I type London now, There you go. So, yeah, that's that's pretty. I mean, I should round this. But that would be more or less all the functionality. And of course, I could go for another layer of CSS to make this look all pretty.
What would you use when doing the styling? In the past, I use a lot CSS in JS, just because it's easy to add certain interactivity here. For example, if we want some infield validation, with CSS in JS, it's super easy to color things depending on JavaScript values. Um, I use style components in React. We could also use plane CSS, but it's just a lot better if we have components, if we also scope our CSS to our components.
You know, one question I have about this, it's how would you go about testing this application? And um let's split it between the the business logic. You have an integration with the API. And then we have the um React application as a whole. So just a few words about how would you go about testing this if you had more time? So, if I had more time, the number one thing I would do is to extract some components.
Right now, everything is all together, which makes it very hard to test. And I would assume we're going to have a component for each one of those fields, and uh I would unit test all those components separately if they have any any logic. and then probably for the whole form write some sort of end-to-end test with Cypress. What about the integration with the API? How would you test that if you if you had a real API? I would probably just mock the API calls and use Cypress fixtures to literally mock this and and write end-to-end test. I see that we are using a lot of effects. What would be a drawback of having so many effects in the application right now? Uh, sure. So, let me take a look. Oh, perfect. We're using two of them here and another one here. The main problem would be that this will trigger a lot of re-renders, so because effects they trigger after the render and then trigger another render. So, I think one of the things we can do is to somehow eliminate some of them, if we move this state transitions in the um, event handlers. As you see, we have this on change event handler all the time. Instead of, we could actually, for example, have a expense name, set expense name, we could actually add it. For example, if I I could take it from here, and just kind of repeat it all over here. Every time I have an on change, do that, and then I could eliminate that effect, that would be number one. The same goes for this one, and the other one, uh, the one where we fetch data we could eliminate with use query. So, we can probably write all this component without using any use effect. Makes sense? Awesome. Okay. Um there's going to be a second part of this interview where we will probably dive deeper into issues like testing, styling, and extending this application. Also, check the description of this video, you will find a bunch of resources to help you fast track in your developer career. If you want Bogdan Knight to personally mentor you, to move to senior developer, to get a confident, competent senior developer and beyond, then you can also book a chat with me and see if our premium mentorship program would be the right fit for you. With that being said, thank you Bogdan as always.
And we will see you in the next one.