Senior Frontend Developer Interview Questions 2024

Summary

In this video, Senior Dev and bden explore advanced front-end topics, focusing on webpack, CSS-in-JS, React, and web performance. They discuss webpack's role in module bundling and tree shaking, the dynamic capabilities of CSS-in-JS, and React's component patterns including error boundaries and hooks. The conversation delves into state management strategies, the balance between essential and derived state, and the implications of using React context for state. Testing approaches for React applications are examined, emphasizing the importance of a mix between unit, integration, and end-to-end tests. The discussion concludes with web performance optimization, particularly focusing on improving First Contentful Paint (FCP) and considering server-side rendering for faster load times.

Takeaways

• 🔧 Webpack is a module bundler primarily used to combine multiple JavaScript files into a single bundle for efficient loading.
• 🌳 Tree shaking is a technique used by Webpack to remove unused code from the final bundle, optimizing the application size.
• 🚀 Webpack's tree shaking requires ES6 static imports and won't work with CommonJS dynamic imports, which are evaluated at runtime.
• 🌐 Dependency graph is a structure built by Webpack starting from the entry point, tracing all imports to form a tree of modules.
• 💄 CSS-in-JS allows for dynamic styling by writing CSS inside JavaScript files, enabling style changes based on component state or props.
• 🚨 CSS-in-JS can lead to larger bundles, difficulty in caching styles, and challenges in debugging due to generated class names with unique hashes.
• ⚖️ React's PureComponent helps in preventing unnecessary re-renders by shallowly comparing props and state, but is less necessary with Hooks.
• 🛡️ Error boundaries in React catch JavaScript errors in child components, prevent the error from propagating, and allow UI recovery.
• ⚙️ useEffect Hook in React is used for handling side effects, such as API calls or subscriptions, in function components.
• 🔄 React's Context API is suitable for managing global state like authentication and user settings that affect the entire application.
• 📊 Code coverage is important but should be balanced; aiming for 60-70% in front-end applications can be practical while avoiding the pitfalls of excessive testing for the sake of coverage.

Q & A

What is Webpack and what is it used for?

Webpack is a module bundler primarily used for bundling JavaScript files into a single file. It was necessary because browsers required a script tag for each JavaScript file, which was impractical for large applications with many files.

What is tree shaking in the context of Webpack?

Tree shaking in Webpack refers to the process of eliminating unused code from the final bundle during production. It identifies and removes modules or parts of modules that are imported but not actually used in the code.

How does tree shaking work with ES6 static imports in Webpack?

Tree shaking works with ES6 static imports because Webpack can understand and track these imports to build a dependency tree, allowing it to determine which parts of the code are not used and can be removed.

Why can't CommonJS modules with 'require' be tree shaken by Webpack?

CommonJS modules with 'require' cannot be tree shaken because they are dynamic and evaluated at runtime. Webpack cannot use these to build a dependency tree to determine which code to drop, as it cannot predict what will be executed.

What is a dependency graph in Webpack and how is it used?

A dependency graph in Webpack is a structure that Webpack builds from the entry point of the application. It traverses all import statements to form a tree structure that represents all modules. This graph is used to optimize the bundle by determining which modules to include or exclude.

What is CSS-in-JS and why is it used?

CSS-in-JS is a technique where CSS is written inside JavaScript files. It allows for dynamic styling based on JavaScript variables and state, enabling styles to change in response to user interactions or other runtime events.

What are some disadvantages of using CSS-in-JS?

Disadvantages of CSS-in-JS include the inability to perform certain CSS optimizations like caching, making the CSS non-cacheable and potentially increasing load times. It can also complicate debugging due to unique hash class names generated by tools like Webpack and may lead to performance issues like cumulative layout shift.

What is the difference between a Pure Component and a Functional Component in React?

A Pure Component in React is a class component that avoids unnecessary re-renders by comparing incoming props with existing props. A Functional Component is a component written as a JavaScript function, which can use Hooks to manage state and side effects without the need for a class-based approach.

What is an Error Boundary in React and why is it used?

An Error Boundary in React is a component that catches JavaScript errors anywhere in its child component tree, logs those errors, and displays a fallback UI instead of the component tree that crashed. It helps in isolating errors and preventing the entire application from crashing.

Can you explain the useEffect Hook in React and its purpose?

The useEffect Hook in React is used to perform side effects in function components. It allows you to perform operations such as data fetching, subscribing to subscriptions, or manually changing the DOM in response to state or prop changes.

Why shouldn't you use an async function as a callback to useEffect?

You shouldn't use an async function as a callback to useEffect because useEffect expects a cleanup function to be returned, which allows for cleaning up side effects. An async function implicitly returns a promise, which React cannot use as a cleanup function, leading to potential memory leaks or unintended behavior.

Outlines

00:00

🛠️ webpack and Frontend Tooling

The paragraph discusses the role of webpack as a module bundler in frontend development. It explains how webpack consolidates multiple JavaScript files into a single bundle to optimize browser performance. The conversation covers the concept of 'tree shaking' in webpack, which eliminates unused code from the final bundle for better performance. The speakers also touch on the importance of using ES6 static imports for effective tree shaking and the challenges with CommonJS imports. Additionally, the concept of a dependency graph in webpack is explained, which is crucial for module bundling and optimization.

05:01

💅 CSS-in-JS and Its Impact

This section delves into CSS-in-JS, a technique that allows embedding CSS directly within JavaScript files. The speakers explore the benefits of CSS-in-JS, such as dynamic styling based on component states and variables. However, they also discuss the downsides, including the reduced ability to optimize and cache CSS, making it non-cacheable and potentially leading to larger bundles. The debugging complexity due to webpack-generated class names with unique hashes is also mentioned, along with performance implications like cumulative layout shift and the creation of a deep component tree.

10:01

🔄 React Components and State Management

The discussion shifts to React, starting with the concept of a 'Pure Component' in React, which helps prevent unnecessary re-renders by comparing props. The conversation then moves to 'Error Boundaries,' components designed to catch and handle errors in child components, preventing the entire application from breaking. The use of React Hooks, particularly 'useEffect,' is explained, highlighting its role in managing side effects. The difference between essential and derived state is also explored, emphasizing the importance of minimizing state for better performance and maintainability.

15:02

📊 State Management Strategies in React

The paragraph focuses on strategies for managing state in React applications, especially when dealing with backend data, authentication, and user settings. The speaker suggests different approaches based on the nature of the state: using local component state for data that's not widely used, React Context for globally accessible authentication state, and potentially Redux or useReducer for complex state transitions within user settings. The trade-offs of using React Context, such as increased re-renders, are also discussed.

20:02

🔍 Implementing Testing in React Applications

This section addresses how to implement testing in a mid-sized React application that previously had no tests. The speaker advocates for a balanced approach, focusing on end-to-end (E2E) tests to cover features, unit tests for reusable components, and strategic integration tests. The importance of code coverage is discussed, with a recommendation to aim for 60-70% in frontend applications to ensure test reliability without overdoing it. The speaker also shares experiences from different companies, highlighting the challenges of enforcing high code coverage percentages.

25:04

🚀 Web Performance Optimization

The final paragraph discusses web performance, specifically focusing on the First Contentful Paint (FCP) metric. The speaker identifies common causes of a bad FCP score, such as large client-side JavaScript bundles, lack of CDN usage, and excessive CSS in the header. Strategies for improving FCP include setting up a CDN, code splitting, and potentially using server-side rendering for very large applications where client-side rendering is too slow. The speaker also notes that server-side rendering adds complexity and should be considered based on the application's needs, such as SEO sensitivity.

Keywords

💡Webpack

Webpack is a module bundler primarily used for JavaScript applications. It packages various files into a single bundle, which is crucial for optimizing load times in web browsers. In the script, Webpack is discussed as a tool for enhancing frontend development efficiency by reducing the need for multiple script tags and enabling code optimization techniques like tree shaking.

💡Tree Shaking

Tree shaking is an optimization technique used in Webpack to remove unused code from the final bundle. It helps in reducing the size of the JavaScript files sent to the client, thereby improving performance. The script mentions tree shaking as a feature available in Webpack 5 and its dependency on static ES6 imports to function effectively.

💡Dependency Graph

In the context of Webpack, a dependency graph is a data structure that represents all the dependencies within a project. Webpack uses this graph to determine which modules to include in the final bundle. The script explains how Webpack builds this graph starting from the entry point and traversing through all import statements to optimize the bundle for production.

💡CSS-in-JS

CSS-in-JS refers to the practice of writing CSS styles directly within JavaScript files. This approach allows for dynamic styling based on component state and props. The script discusses CSS-in-JS as a solution for interactive styling needs in modern web applications, highlighting its advantages in creating dynamic styles and mentioning the challenges it poses in terms of caching and debugging.

💡React

React is a popular JavaScript library for building user interfaces, especially single-page applications. It is mentioned throughout the script as the framework of choice for the discussed projects. Topics such as React components, hooks, and error boundaries are explored in relation to React, emphasizing its role in modern frontend development.

💡Pure Component

A pure component in React is a type of component that prevents unnecessary re-renders by shallowly comparing its props and state. The script explains that with the introduction of hooks in React, the need for pure components has diminished since hooks inherently provide similar performance optimizations.

💡Error Boundary

Error boundaries in React are special components used to catch JavaScript errors anywhere in their child component tree and handle them gracefully. The script discusses their utility in preventing a single component's error from crashing the entire application, thus improving the application's robustness and user experience.

💡useEffect Hook

The useEffect hook in React is used to perform side effects in function components. It allows for operations such as data fetching, subscriptions, or manually changing the DOM. The script touches on the proper use of useEffect, its impact on performance if misused, and the importance of returning a cleanup function to prevent memory leaks.

💡State Management

State management in the context of the script refers to the strategies used to handle and distribute state within a React application. It includes discussions on local component state, global state using React Context, and complex state logic potentially requiring external libraries like Redux. The script emphasizes the importance of choosing the right state management approach based on the application's needs.

💡Code Coverage

Code coverage is a metric that measures how much of an application's code is executed during testing. The script discusses the balance between high code coverage and practical testing strategies, suggesting that while high coverage is desirable, it should not lead to writing tests that do not add value, and that maintaining a coverage level of 60-70% is a good target for frontend applications.

💡First Contentful Paint (FCP)

First Contentful Paint (FCP) is a web performance metric that measures the time it takes for the first piece of content to be rendered on the screen after a user navigates to a webpage. The script identifies FCP as an important metric for user experience and discusses various optimization strategies to improve FCP, such as reducing JavaScript bundle size, using a CDN, and implementing code splitting.

Highlights

Introduction to senior frontend interview questions by D and bden.

Explanation of webpack as a module bundler and its necessity.

Discussion on webpack's role in optimizing JavaScript file handling for browsers.

Experience with webpack configurations and project setups shared.

Tree shaking in webpack to eliminate unused code for optimized bundles.

The importance of using ES6 static imports for effective tree shaking.

Challenges with tree shaking and dynamic imports using CommonJS.

Understanding webpack's dependency graph for module management.

CSS-in-JS explained as a solution for dynamic styling with JavaScript.

Advantages of CSS-in-JS for immediate style changes based on state.

Disadvantages of CSS-in-JS including caching issues and increased bundle size.

Impact of CSS-in-JS on debugging and performance due to component re-renders.

React's Pure Components and their role in preventing unnecessary re-renders.

Error boundaries in React for localizing and managing errors in components.

Use of React Hooks, specifically useEffect, for handling side effects.

Why async functions are not suitable as callbacks for useEffect.

Strategies for state management in React applications with various requirements.

Difference between essential and derived state in React components.

Disadvantages of placing state in React Context, such as increased re-renders.

Approach to testing a mid-sized React application with no existing tests.

Importance of balancing unit, integration, and end-to-end tests in a React application.

Code coverage as a metric for testing effectiveness and its appropriate levels.

Real-world experiences with code coverage expectations in different industries.

Explanation of FCP (First Contentful Paint) and its significance in web performance.

Causes of a bad FCP score and strategies for improvement.

Considerations for server-side rendering to enhance FCP in large React applications.

Conclusion of the discussion and预告 of future content.

Transcripts

hi folks D here from the senior Dev and

uh today together with bden we're going

to go to a bunch of senior frontend

interview questions these are real

interview questions that we've got

ourselves in senior front interviews but

also our mentees number one we're going

to start talking about tooling right and

the first question is can you tell me

about your experience using webpack what

is it use for uh weback it's a module

bundler so we basically use it to uh put

several JavaScript files into a single

one that used to be necessary because in

the browser um you basically in order to

add JavaScript you need to place a

script tag for every Javascript file you

have and when you have a big application

with hundreds of files that's just not

practical so bundle um weback will uh

will kind of bundle all that it will

parse all of them and based on your

imports and exports and put them all

together into a single bundle and then

we can apply different optimizations um

I worked a lot with weback in the past

basically setting up projects from

scratch and doing all kinds of

configurations yeah nice Bon are you

familiar talking about weback and module

bunders are you familiar with the term

tree shaking three shaking as in weback

it's basically what weback will do when

we ship our bundle to production and it

will basically try to find that code

those are modules that maybe we imported

in our code but we're not really using

or parts of modules and it will

basically try to eliminate them so our

bundle is as small as possible and we

get the best web

performance amazing have you used um

tree shaking professionally in

production uh at any stage can you uh

give me an example of

that uh yes as far as I know in version

five it comes by default so every time

we use weback it will try to T Shake our

code one thing you want to be aware of

is that it only works with es6 static

import so if you have any any module in

your dependencies or you're using

commonjs Imports with require then weac

cannot really appre shake that so you

got to be careful because yes weback

ships with it by default but if we don't

use those kind of modules then it's not

capable of really understanding if it

should remove that code or it's not

being used which modules where uh so us

six static inputs are the ones that do

uh allow weback to do three shaking and

commonjs you know the old require

notation those ones cannot be three

shaked because they are Dynamic and they

are evaluated at run time so they they

are basically functions and weback

cannot really use them to build this

dependency tree and figure out okay

what's going wrong in there can I drop

any of that code until it gets executed

in the

browser excellent seems like you know

quite a bit about weback now um what is

talking still talking about weback and

and tooling and module bunders um you

know what is a dependency graph and what

is it used for in weback uh the

dependency graph in in weback it's

basically what weback builds from our

entty point so it'll basically take our

first file and then figure out and go

down all those import statements we have

at the top and from that it will keep

going down until it reaches basically

the end and that's basically a three

structure that it forms and that's how

it stores basically all our modules and

then it's using that to uh transverse it

to go through it and find out if there's

any modules we need to drop or which

ones are in production so it's the kind

of the main abstraction in web pack and

it will always be used to put you know

to go from Individual files to a single

bundle cool now we're GNA move on with a

question about CSS injs basically can

you explain what CSS injs is and can you

give me an example you know what are um

what are some use cases for CSS

injs uh yeah sure so CSS injs appeared

because we writing all this JavaScript

and we have a lot we have a lot of

interactivity and we basically want um

to change CSS Styles when a certain

state or certain variable changes and

CSS injs allowed us to um to basically

have Dynamic CSS where you click a

button and some CSS CH changes

immediately um you could do that with

classes like you would assign a

different class to an element but it's

just a lot easier if you could just swap

colors or directly do things with

JavaScript variables inside CSS that

usn't that was not possible before

because you had static CSS files uh and

with CSS injs we write our

CSS inside JavaScript files and then

webpack will basically somehow extract

that and build different classes and

attach them to attach them to um to the

um to the JavaScript uh to the HTML Dome

at run time but we don't need to worry

about that so it basically allows you to

write your CSS in JavaScript and

leverage a lot of dynamic dynamic Styles

so you have the dynamic language like

JavaScript but you can do styling with

it awesome so you already mentioned some

of the advantages right of having

JavaScript control um variables inside

your styling but what are some

disadvantages of using CSS

injs uh well one of the main

disadvantages is that because your

styles are now in Javas in JavaScript

files you cannot really extract them and

do certain optimizations you can do to

CSS um and one of the thing is you

cannot really cach your CSS files so if

your CSS didn't change back in the days

you could have the user uh storing that

and browser side because you attach a

cash policy with HTP headers to it like

cash control and they would store that

and in a subsequent visit they wouldn't

have to download all your CSS but now

all that CSS it's inside our uh

Javascript file JavaScript bundle it's

all together which makes our bundle

bigger um it's a bit harder to price but

it's also non-cashable uh you can

actually counteract that by extracting

uh with web pack your CSS at run time um

and ship it separately uh but it's still

still not as easy as it used to be when

you had your CSS separated from from

your

JavaScript understood it's also harder

to debug your CSS uh because again those

classes that weback generates they're

unique hashes and all of the sudden it's

not as easy as it used to be to

understand why a certain element looks a

certain way there is some tooling right

that um csjs usually brings on to make

that debugging easier um one thing you

we haven't chatted about it's the the

performance um how how how does it

affect how does CSS njs affects

performance so that's uh one of the main

things is because you cannot cash your

CSS you're loading it and it will

decrease um the performance and um yeah

it will also you might also have a lot

of uh cumulative layout shift because

your CSS gets now applied when uh when

the JavaScript bundle gets pared so um

in the critical rendering path we

usually evaluate CSS first and we apply

it and that ensures the fact that

there's no flash when you load the page

but now because we evaluate the CSS at

the end you might have cumulative layout

shift when the user loads the page

things might move around and you got to

be careful uh and sometimes split your

CSS and ship CSS injs for the dynamic

parts and then still use PL old CSS for

most of your grid elements so you have a

stable page and the other thing is

because we are creating new components

for example iio style components in

react every every time we style a

heading or a native react element we end

up creating another component and in a

big component three that will create a

huge component layer uh which it's

always a huge component Tre a very deep

component Tre which is always a

disadvantage because it makes debugging

harder and of course a bigger component

Tre it's also harder for react to

reender all the time even if react is

very um effective you want to keep it as

small as possible awesome V then we're

going to move on to the next question um

and we will talk about JavaScript

Frameworks specifically react um have

you worked with react in production so

far uh yes I worked with react for the

last uh pretty much since 2015 so that

will be around pretty much since it came

out yeah awesome then you're probably

gonna fly through these questions uh

first question is you know what is a

pure component in

react uh pure component in react well I

think so pure component used to be uh

when we had components and you wanted to

avoid the reenders you use one of those

because it would compare the incoming

props with the existing props and if

they were the same it would skip the

render um You probably don't need it

today because we use Hooks and hooks are

by default memorized so whenever you do

a whenever you do a set State um react

already checks if you are updating the

state to the same value and if that's

true it does not reender the component

so it kind of comes by default but back

with class components we had to use pure

compon components cool um another

another type of component uh question is

what is an error boundary component you

know what is it used for why do we have

error boundaries components in

react uh yeah sure so basically error

boundaries um help you limit the impact

of an error so if you have a data

fetching error in some component you can

wrap it with an error boundary and that

will uh at some level localize the error

so doesn't go up the component three and

you don't show the whole thing the whole

application broken but you can actually

show a placeholder for that one

component that um something went wrong

uh so it allows you to localize and have

a much better predictable UI and also

have no layout shift when you have the

servers they can totally destroy the UI

if they're not managed awesome very well

um now still talking about react in this

case we will focus on react Hooks and

the hook that we are talking about is

you know are you familiar with the use

effect hook tell me more about how is it

used um you know what would be some

advantages and disadvantages of using

use

effect uh yeah sure so we basically use

effects to uh trigger a what you call a

side effect in react that would mean uh

when a state variable changes maybe

imagine we want to do something else

like we want to make a call to our

analytic system and to tell something

changed or write into local storage for

example example that would be an ideal

case for effect um I know when they came

out um myself included and all the

community kind of abused effects and we

using them for everything so we would

use effects to change a different when

one state variable change we use effects

to change a different uh variable but

the thing with defs is that they U they

run after the component reender and they

trigger another reender so if you're not

careful and you abuse them you end up

having so many reenders in your

component and of course reenders of

parent uh will cause reender of a child

component so that will really it can end

up affecting your application if you're

abusing them um performance- wise second

question about use effect hookit why

can't we use an as async function as a

callback to use effect well probably

because in a sync function returns by

default the promise and the return of

the use effect hook should always be a

cleanup function that allows us to if we

for example in the effect attach

something to the on scroll effect to

remove that Handler because if we don't

remove it and we end up re rendering we

keep attaching handlers to that event

and we might bloat the browser so react

allows you to return that cleanup

function but when you use a sync you're

always returning a promise and react

doesn't know what to do with that

promise because it's not it's it expects

a function so that's why uh you get this

lary iting most of the times that tells

you hey you cannot you cannot use an an

sync function here yeah

awesome totally makes sense we are going

to move on with a question about State

okay and I want you to imagine that we

have a simple front end application with

the following State okay number one we

will be fetching some data from the back

end right then we perform some user

authentication and um set some general

user settings that will affect those

those um user settings will affect the

whole application and my question is you

know when we have to do with such

requirements on the client side what

would be the best solution to handle

State Management in this application and

why uh sure okay so we have backend we

have data we get from the back end we

have authentification state that you

mentioned and some global settings right

yes um okay so I'll probably Place those

differently because of the requirements

on them uh so usually uh from my

experience data that comes from the back

end can stay in component State unless

it's needed by two or three components

where you could usually just um lift it

up and you'll have a bit of prop

drilling but it should be manageable

with that kind of data um when you have

authentification State you usually want

that to be globally available to any

component because some components might

need it to see the user goals and

permissions that's why I'll probably use

something like react context because

it's very useful to broadcast uh the

state through the whole component Tre

and for the settings um it looks like

there might be some non-trivial State

transitions in the settings usually if

you have maybe complex transitions like

a user can be premium or not and that

will change many different settings

across the apple is that's what I worked

with in the past uh in that case you

might look at the state machine or you

might need a reducer pattern you can of

course use something like Redux for that

or a smaller like a twoand library but

you do need a reducer pattern when you

have these complex State transitions um

you can use use reducer with context

that also works uh so that's how I would

um that's how I distribute State these

three different ways cool um now still

sticking with State um one question

about essential and derived State

specifically could you explain the

difference between essential and derived

State uh the difference between

essential and the state uh so basically

essential state would be state that um

changes by itself changes independently

and you cannot use it any further and

the I state state you could calculate

based on the essential state so just to

give an example if you had a component

that displays like a breakdown of a

shopping cart all the different items

that you add there they're probably

essential state but the total and the

vat amount they are the state because

you can compute that based on all the

other items so that would be an example

and usually you want to keep as little

State as possible so you want to have

only the essential state in your state

hooks in react amazing cool um now final

question about State and react uh you

know what would be the disadvantages of

placing State inside react context i'

would say number one is that if you lift

state so far up anytime that state

changes every component that will be

connected to that uh context

will also change so if you have state

that really changes independently and

it's consumed by different components

you could also split it into different

react context to different providers

because the components that will

subscribe to those will be different

you'll have overall less reenders uh so

that's one of the biggest problem when

you lift state in general but especially

when you lift it to context it will end

up causing reenders and as a gener rule

I try to keep state or we should all try

to keep State as close to where it's

being used yeah amazing bton um yeah we

have a bunch of questions two more two

more categories um I will be asking you

about uh we're gonna start with testing

right and uh specifically you know how

would you go about testing a react

application yeah what you know if any

let's think about a midsized application

not too big not too small uh there are

no test let's see development team was

pretty crazy they've written no test

they just you know usually happens we've

seen that in companies but they stitch

together a bunch of components there's

data fetching there's authentication

there's all all the kind of

functionalities that you find on a

client side application built with react

how would you go you know you are hired

to um bring that up to to implement some

best practices in that one specifically

testing how would you go about testing

this kind of

application uh okay so we have a react

application that haven't been tested um

I would probably inspect the codebase

and try to decide either we want to do

unit start with unit test or uh

integration test or entn test which is

the typical testing pyramid um I

probably in my experience in the front

end one of the best tests to have are

entend tests because you test the

features which is very clear and then it

allows you to refactor your code behind

it without changing the test um and if

we have any components that we reusing

like imagine we might have input fields

that are being reused or buttons or any

kind of component that has ideally some

logic and is being reused like a drop

down

in that case I would write some unit

test on them I'm not a fan of unit

testing everything just because in react

you didn't get a lot of value for

testing pure components like just if an

image renders uh we could do that some

people do that in order to hit the code

coverage uh but I would say having some

good ENT test having unit tests on

reusable components and strategically

choose some integration test uh should

be the way to go and how do you know you

how do you strike the perfect balance

between ENT test unit test and

integration test in the front

end uh that's a very very good question

um I would

say you need to understand if we write a

lot of entend tests but we have imagine

no unit test and integration test what

will happen is that when your entry test

fail fails it it's good you know that

there is a bug but it will be extremely

hard to go through the code and find

exactly where it is so the more unit an

integration test you have the easier it

is when you find a bug to localize the

when you make root call analysis to

localize the the bug boundary and really

eliminate all the other sides of the

application if you only write 10 to0

test uh you will have coverage for your

features but when something breaks it

will still take you hours to debug so I

would say uh I would be smart about it

and understand your application and then

have a have a certain balance I cannot

give you exact numbers but I would write

a lot of unit test and a lot of ENT test

to finish the feat to cover the features

and strategically some integration test

on on the critical features like if you

have login or if you have payments you

got to see also like what's more

critical in your

product uh you did mention the word code

coverage when you were talking about

unit testing um you know can you tell me

more about code coverage like just

shortly what it is and um what would be

the appropriate amount of code coverage

in your opinion in a fronted

application uh so yeah code coverage

it's the amount of code that EX executes

when we run the test basically so people

say it's the amount of code we cover in

we cover it with test but it's actually

the amount of code that actually

executes when you onun the test um in

the front end I would say it's a bit

more tricky than in the back end where

it's a bit easier but I would try to

keep it all the way up to 60% whenever

possible if you go under 60 then it will

be quite unpredictable and the test are

unusable because you can't really trust

um there's a lot of code that's not

tested so the test might fail but you

don't really know why do I failing so 60

to 70% would be good I think going over

80 to 90 it's a bit of an Overkill and

you didn't get a lot of value from those

marginal test um in your last uh Team or

company you know what was the code

coverage you were aiming for and you

know did you had any anecdotes anything

that you can tell us how did it went for

you um yeah sure so at least in some of

my roles I worked in the finance

industry where they they made it was a

general rule for the company to have

around 9 5% of code coverage uh we ended

up writing a lot of test that made

literally no sense um you you have a lot

of files that sometimes are just

explicit they decare types you had to

exclude all those and it was pretty much

of a hard measure everybody was saying

they do tdd but in the end everybody go

test before pushing their PR um so I'll

be really careful with these measures

because in the end people say they would

do it and so on but uh but yeah I had

that experience I also been in teams

that didn't wrote any test at all to be

very honest there was uh CS that was a

disaster and I would say the perfect

balance is in the front end 60 to 70 in

the back end I would go a bit more up 90

to 80 80 to 90

95 uh it's still doable because the back

end again it's it's a bit more

functional and it's sometimes much

easier to un need to test or to

modularize things and it is in the front

end cool now um let's talk finally final

uh final category we will talk about web

performance right um and question here

is

can you explain

FCP okay what are the causes of a bad

FCP score okay so FCP FCP would be the

first contentful paint uh which is

basically the time it takes since the

user hits the uh the enter button in the

browser to display something and to

display anything to them um and usually

it's really bad if you ship a lot of

JavaScript that is client side Ender so

it takes a lot of time to part all this

react bundle and interpret it for the

browser to show something or you don't

use a CDN so maybe the assets are not

compressed or they're not cached and so

it it literally just takes a lot of time

to to do that or you have a lot of CSS

uh CSS CSS in the header uh has to be

all interpreted before we move on to

JavaScript and finally start

incrementally rendering the HTML um so

if you have a lot of that it will also

take a long time so these are three CES

that I've seen in the past

that's the first thing I would look at

let's suppose you take charge of a front

application you run your um analysis

whatever tool you use Lighthouse For

example and you realize that the FCP it

has a very low FCP score how would you

go about fixing

it uh so okay so we saw that the FCP is

low on lious I definitely r a couple of

analyses just to make sure the score is

legit and once we have that uh I

probably as I mentioned look first into

the CDN it's usually easiest thing to do

and gets a lot of benefits if there is

not one set um and then probably I would

uh use something to inspect the bundle

and see if we can remove any part of the

JavaScript that's not being used and if

that doesn't still work I will look into

code splitting and really only load the

JavaScript that you need for a specific

page I'll probably talk to the product

managers and see which are the pages

that are more critical for us to to load

fast usually it's not all the pages and

I would focus on those ones and load

split to make sure that uh we really

load as little JavaScript as possible

and maybe defer some some of the

JavaScript or a sync loaded uh you can

do that with weback uh with react. lazy

also you can split your component Tre uh

so basically code splitting would be one

of the biggest um things I will do after

we add the CDN and we make sure we have

caching and compression in place so

number one CDN caching compression

number two remove um whatever Li lies

that you can remove that are adding way

too much JavaScript to the bundle uh

number three code splitting and and

shipping different chunks of JavaScript

as you need them right to make that

lower have you considered and when do

you consider something like server side

rendering let's suppose this is a react

client side um client side rendered

application and you've went with all the

optimizations and still because of the

size of the application the application

is too big and the FCP it's way too slow

um would you consider server side

rendering what would you know would that

improve the situation or

not um server side rendering when done

well it will definitely improve uh by

basically removing by basically yeah

showing instantly we ship the render

HTML to the client so they will get

something immediately they'll see

something uh it does add however

complexity to your code base so I know

in some use cases where people rushed

into Ser side then they had to roll it

back I would definitely look at our

product and if the product is very

sensitive to loading speed or sensitive

to SEO then you'll get a lot of benefits

from server side gring but if it's not

if it's like a sass application where

it's like accounting software then

there's usually no value in serite

rendering so you would stick to CSI

still because it's not yes yeah probably

in e-commerce in something like

e-commerce or the media where you have a

newspaper they want to load very fast

and they're very sensitive to SEO

they're probably most of them using

serviceing asome ban this was it for

today we uh covered a lot of topics from

CSS injs to react react hooks to weback

to tooling to testing and now on to

Performance I hope you um folks enjoy

this we um we're going to publish some

more series on this thank you B for this

one and we will see you in the next

one see you in the next one