paint-brush
What I learned from building a chat project with sockets.io and Reactby@alexcloudstar
379 reads
379 reads

What I learned from building a chat project with sockets.io and React

by Alex CloudstarAugust 13th, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

A few days ago I’ve built a React application with socket.io. I noticed that on a lot of messages my app starts to be slow and do some lag spikes. I used callbacks that didn’t help a lot because I had almost all of the state at the root of the app and I basically killed the memoization. After some I did some search on Google, and I found an article with a developer who had the same issue. The awarded response was to use socket.off into the cleanup function of useEffect. After I tried this one, all the apps worked like a charm.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - What I learned from building a chat project with sockets.io and React
Alex Cloudstar HackerNoon profile picture

A few days ago I’ve built a React application with socket.io. It’s a chat app.


*Sidenote: The repo and youtube video will be at the down of the article. Now, when you’ll see it you may ask a few questions like, “why didn’t use any DB or firebase?” or something. Well, is simple I had 3 main reasons:


  1. My experience let me to that, is not like I couldn’t implement firebase or MongoDB (because I love mongo) or any DB
  2. I wanted a minimal app, and if someone finds my code usefully it can take it and implement which DB wants or any backend architecture
  3. It was a Lil bit simple to do it with DB and a little bit overkill at the same time to use that


Anyway, getting back on rails. In the progress, I was developing features like emojis, showing when another user is typing, set usernames and so on, I noticed that on a lot of messages my app starts to be kinda slow and do some lag spikes.


Of course, as every React Developer does, I start to throw memoization. I used callbacks that didn’t help a lot because I had almost all of the state at the root of the app and I basically killed the memoization; it was doing the shallow comparisons for props, but when any prop was changing, the other components were changing (basic logic, right? Right) so I started to refactor all the app.


*Ups, sidenote again:

Yes, I didn’t use any state management because I didn’t want to. Again, if someone wants to take the code, it could implement which state management he wants like Redux, Context, or maybe MobX (didn’t try this one, maybe I will in someday 🤔).


After all, the refactor, yes it was a little bit better - but on a lot of messages it was still spiking.


The memoization and callbacks were in place, the refactor was there, I just finished a few seconds ago. But what was the issue?


Well, after some I did some search on Google, and I found an article with a developer who had the same issue. One and the awarded response was to use socket.off into the cleanup function of useEffect. After I tried this one, all the apps worked like a charm.


Here’s an example code:

useEffect(() => {
		socket.once('chat', (data: messagesStateTypeWithMessageStateType) => {
			setMessages([...messages, data]);
		});

		messageRef?.current?.scrollIntoView({ behavior: 'smooth' });

		return () => {
			socket.off('chat');
		};
	}, [messages, setMessages]);


So the point of the story is:


Is fine to open things, but remember to close them after you finish.


Thanks for reading,

Don’t forget to like, share, and subscribe.

Until next time, don’t forget to close things after you finish you use them.

Cheers!


Resources: