How DAN.com Uses the DAN React Pattern for Faster, Easier Development

Christian Vogel, Software and Product Engineer at DAN.com, says that creating their own React pattern at DAN has helped them streamline their software development. In short, it removes the need to make state management a priority, which not only makes Christian’s coding faster, but also — he says — more fun. In this podcast conversation, he shares what the DAN React pattern looks like on a component level, how it’s set up, the practical impacts it’s had on his team’s workflow, and some things to consider when setting up your own React pattern.

Follow our conversation by using the chapter breakdown below, or check out the full transcript of the episode.

Also, we encourage you to reach out to Christian after listening! Make notes during the episode of any questions or comments you think of, and message him via LinkedIn or Twitter — he’ll gladly answer any questions you have!

Christian_Panda-thinking-Pattern_How-DAN.com-Uses-the-DAN-React-pattern-for-Faster--Easier-Development_Inner-Article-Image

Podcast chapters:

[03:42] Intro to Christian’s role at DAN.com, and what they do as a company

[06:32] What is the DAN React pattern?

[09:07] Benefits of the DAN React pattern for DAN.com’s software development

[12:56] How the DAN React pattern works: Components and setup

[16:57] Use cases for when (and when not) Redux might be the better pattern

[18:36] Why the simplicity of the DAN React pattern is so useful

[20:21] How this pattern helped build a live, internal ‘alert system’ within two weeks

[23:19] The potential for this kind of React pattern

[24:22] Christian’s advice for anyone wanting to build their own React pattern

[27:12] Final summary, takeaway points, and closing thoughts

Transcript, with chapter timestamps:

Jomiro: Christian, welcome to the OfferZen podcast. It's really nice to have you with me.

Christian: Thank you for having me.

[03:42] Jomiro: So I've obviously spoken to you at length about what you do. And I've got some insight into your company, DAN.com. But just for anyone who's listening and maybe hasn't heard of you or DAN.com before, could you just give some insight into what you actually do at DAN.com ? Like, what problem are you trying to solve as a company.

Christian: DAN.com is an online marketplace for domain names. And, but we try and do it a little bit differently than all the others. So we focus a lot on technology and transparency. And I'm involved in the technology part of that. So I'm a product developer on some of the innovative new things we’re developing. And I'm also quite involved in the front-end development.

Jomiro: And I'm curious to know, is there a reason that your domain name is DAN.com?

Christian: Well, it stands for domain automation network. So what we are aspiring to be is a place that connects all of these domains, transferring all these things together and makes it into a seamless whole. This is something we're working on and we want to evolve. But in the end, we wanted to make it really easy for people to get the domain they want, to make it affordable, to make it easy to transfer these and the current domain market is just a bit outdated. I mean, many domain companies work on computers from the 1990s. There has not been a lot of innovation going on there. So DAN tries to upset that and to modernise the main market.

Jomiro: I didn't realise it was such an innovative space to be in but that's really interesting to hear. And you're all based in Amsterdam, or are you sort of spread out?

Christian: We're based in Amsterdam, yes. Cool. We're working a lot of remote as well. But yes, we are based in Amsterdam.

Jomiro: So that remote-first approach with COVID-19 wasn't such such a big move for your team, I assume.

Christian: I don't think we were remote-first, but we are now forced into it. But it's working pretty well. Yeah. There's always... we are actually quite a close-knit bunch. Lots of people who work really well together. So it is I am missing seeing the other guys at the office.

[06:32] But jumping into the topic of our conversation today: Last time we spoke you mentioned your React pattern that you've set up, called the DAN React pattern, and I'd like to understand a little bit more about that pattern in particular. So, just as an intro, what is the DAN react pattern? What does it look like from from a technical point of view

Christian: It was a way to scratch our own itch. In the company, where we were coming from, it's a very complex system with Redux and lots of layers and React, the React pattern is an internal solution that really simplifies that a lot. So we take out lots of layers and what remains is a way of writing components in a way that feels more natural and allows you to also distribute the state if you want to.

Jomiro: And is that something you set up when you arrived at DAN.com first?

Christian: Yeah, when I arrived at DAN, it was about a year ago, a little over a year actually. I looked at all the code that was there and it was well written. But you know, code accumulates, right? So you get layers and layers. And I wanted to, for example, rewrite the search in our website, and I just noticed that it was really hard to read the code. It was really hard to follow. If you do this, what happens there, what happens then how these, these things are connected.Yeah, one of the solutions was to use TypeScript - that really helped making it much clearer where all these things are connected. TypeScript is just a really nice way of auto-documenting your code, and getting more compiled time feedback on the quality of your code. And the other one was to... I did a lot of research into solutions of simplifying how we managed to state in our code. It felt a bit too heavy.

[09:07] Jomiro: So I think the simple simplification and removing code complexity, and making it easier to read... I think that is intuitively a good thing. But what did having simpler code, and easier to read code mean for your team at DAN specifically? What kind of impact did it have on your development, and maybe you can talk me through an example, from your own experience in your team?

Christian: Well, for example, this search that we built for the old search has a lot more complexity. It had, for example, a Redux store that stored all of this data. It had sagas that were processing this data and these are all good patterns, right? There are very common patterns. It had these connector classes that bound to the state. But I mean, it meant that actually tracking, making changes and tracking the changes in the code was quite hard. And it was another problem. And it was really hard to get Redux to work well, with TypeScript to have clean types. It is possible but is really tricky.

And the solution we already had was using a technical Immutable.js. But the problem with Immutable.js is that it is also untyped. Which meant that the code at the top level bled down all the way into the components and made it, there was no type safety anymore. It's throughout the components, which meant that for me as a newcomer at that point, it was really hard to see how the code was structured. And if I was actually writing correct code, the only way for me to do that was to just run the server, make a change and see if I actually got what I wanted on the screen, which is okay. But if you can avoid all that, then that's actually quite preferable.

Jomiro: So I mean the I think faster development is an obvious knock on effect of that kind of simplification, but I thought what you just said is also really interesting that, for a newcomer, it's easier to understand at a glance what's going on, and not having to first dig through a whole bunch of code and dig through a bunch of complicated code before you can understand the the system at a high levels. I think it’s also interesting that it makes readability for newcomers easier. And I guess that probably takes a lot of strain off of your team having to level someone up into what was there already. That process has probably sped up a lot for you guys too.

Christian: Yeah, it really helps to more quickly interact with the code. And it sounds like a lot, but it's actually not a very complex pattern. It's just something I found out as a mix of existing things that worked really well at DAN.com.

Jomiro: I was going to ask as well... How hard was it to implement this pattern, or to to create this pattern?

Christian: Once we figured out what the combination was, it was actually really easy. There are some “Gotchas”. And yeah, maybe it's good if I explain a bit how the pattern works?

[12:56] Jomiro: Yes, please. That would be great.

Christian: Yeah, so, so this, this pattern is a combination of some things. First of all, you designate a component, a normal React component at a top-level component. And that contains a state just like a Redux app does. Then any subcomponents, any presentation components, the props that you pass to them, you treat them as dependencies. So those components only update if the props that you pass to them update. And that makes the whole reasoning much simpler because you're — already in the definition of the components — telling when they should update if that props change. This is also very consistent with HTML, for example.

What you then do is, all the subcomponents, they have to extend React.PureComponent. And that gives them a different behavior. That means they don't always just update if they get rendered again, they only get rendered again if their props change — which is the behavior we want.

However, one of the things that Redux fixes for you with the mappings is that if a sub property of a component updates, you also want your component to update. So, for example, if I have a To-Do component, and officialises a To-Do in a To-Do list, and you're passing a To-Do and the Done property of that To-Do changes. You also want that To-Do to update right even though at the top level, the property did not change. So normally that component would not self update. The trick here is to use ImmerJS. So, when you update the state in any of your components, and especially the top level, of course, then you use ImmerJS to do that.

And I found out that ImmerJS has this really nice feature, that if you change a very sublevel property, it goes all the way up the chain to change that object. And that means that we magically get… So, if our components update, and we tell the properties what they depend on, it just works.

I said that you pass properties into components, it's the properties changed, and the component knows to update, righty? But you also want to sometimes pass a handler, right? So I would like, if the button gets clicked or the To-Do entry gets clicked, I want to catch that right. That's also property, which means that you don't want the property to change every time. And if you pass a handler closure into a property, then what actually happens is every time you render the property seems, from the React point of view, the property changes.

So, you have to write handlers differently in order for this to work. The handler has to be part of the component. And you have to write them in a more functional way, so that they never change, that they are always the same. So they are not seen as a change to the component.

Jomiro: So it sounds like — maybe not in the true sense of the word — there is some sort of automation going on here where you you can do something once in one place and that it sort of trickles and feeds through the rest of the system where it needs to and it sort of does that for you.

Christian: Yeah, ImmerJS does this for us.

Jomiro: And is that also part of the DAN React pattern?

Christian: Yeah. So you must have all your component changes being done using ImmerJS.

[16:57] Jomiro: Interestingly, though, and I think you've sort of alluded to it in your description just now as well, but when when would it potentially be better to use other patterns, like a Redux for example? What are some of the downsides that you've noticed, or have at least been aware of with this particular react pattern?

Christian: One of the benefits of Redux is everybody knows it. So if you're in a big company, then if you have a new developer that can immediately start using Redux, because it's very common. There's a lot of documentation about it. There's a lot of information about the pattern. So that's definitely a big benefit.

Also, while there's lots of “Gotchas” on Redux as well, you have to stick to the pattern, otherwise it doesn't work. You also get a really nice feature on Redux that can help a lot with debugging. There's nice debugging tools on Redux already. And it allows you to time travel. So for example, if you have this huge app with lots of states, and you want to be able to rollback the state, while your app is running in a browser, with Redux you can do this because the reducers that Redux uses are stateless. So you get this for free. Actually, that would be the reasons for me, that I can think of.

[18:36] Jomiro: And I think also, you know, you said that it was relatively easy to implement the DAN React pattern once knew the configuration and the problem that needed solving, but if React patterns are relatively easy to set up — and the Dan React pattern in particular was easy to set up — I'm curious to know, from your experience, why do you think it may be true that more people don't set up their own React patterns?

Christian: Oh, there are many patterns, and many good ones as well. I think what distinguishes this one from the ones that I've seen is that this does not require any new library. It's really just a pattern. I mean, ImmerJS you can also use it for Redux. Right. It's not something specific to this pattern.

Jomiro: And what is not requiring a new library important for your software development team at DAN?

Christian: You don't need to learn anything new, it's light, and it also means you can use all the standard React code. It feels like programming normal React code. So because the state is just a component state like any other, this means it scales up and down the line.

So for example, let's say I made this To-Do List app, right, and I made this as a component, and it had subcomponents, that can be later a sub component of something else. I don't have a top level store. It's just a component. So it makes the whole state handling not so special anymore. And

[20:21] Jomiro: I'm curious to know as well, Are there examples from like, maybe some projects or things you've worked on at DAN, that sort of illustrates how this React pattern has improved the development from a workflow or efficiency point of view?

Christian: Well, for example, I mentioned the search, but there's also — on our backend — we have the support team, and they need to answer lots of questions, right. And this is coupled to our backend as well. And I said that at DAN we try to help people as quickly as possible to make the whole domain transfer process as automated and as pleasant as possible — so, to also have good support.

That meant that we wanted to find a way to bind what happens in our backend — you know, domain is paid for or something happens with the domain or something goes wrong, we get a message — that there's a streamlined process for our support team to work on that.

So we built a support system that was built using this pattern. This seemed like a good test case for it, since it's internal. That allows us to, if anything happens with the domain, it creates a new task. And that task has like a whole backlog of all the things that have happened with it already. And the messy information about, you know, the circumstances, and who is asking for that task, etc, etc... It's like a ‘thought system’, but it's coupled to our live system. And we wanted to have a real time, quick, responsive system that can handle all this stuff. And we use this pattern for it, and it works really well. No complaints. And it's all in real time. It's like a super fancy To-Do list in a way.

Jomiro: What I think is an interesting point there is, it seems obvious that it improves the experience of developers in your team for a number of reasons, all of which you've mentioned — but a knock on effect is, because your support team can also respond to customers faster, it improves the customer experience in an indirect way as well. Your support team can respond faster and therefore your customers get a better experience on your site.

Christian: Yeah, absolutely.

And the first version of this system was built in like.. within two weeks? Getting it running was really quick using this pattern, because you don't have to think about ‘state’ so much anymore. It felt really natural to do this.

[23:19] Jomiro: So, given all of that, I'm curious to know... You've obviously had some cool use cases for it with your customer support, and also the search function as you were saying... But what are some of the potentials that having this React pattern, or the DAN React pattern? What could you do with it going forward? Or, what are some of the things that you could build now that you've got this particular React pattern?

Christian: Well, for us, it has worked, so well, that we want to use it across the website now. So anything that we update is going to use this pattern if it's React, of course. So yeah, that's that's how we see the future. It's just that I thought it could be useful for other people as well. So that's why we posted it. Yeah, the potential is that we use it everywhere, basically.

[24:22] Jomiro: And do you have any particular advice for someone who's listening to this and thinking that they'd like to set up something similar for their team? Is there a particular lesson that you've learned, that you think would help someone who wants to do something similar?

Christian: Yeah:

Just start with a small project first, to see how this pattern impacts your code. Don't start big. Just start with something small. Every pattern needs a little bit of getting used to.

Especially the passing of the closures, that means that you cannot have state, that you that your post is going to change and how to do that as a bind to your class. That is, I think the trickiest part of the pattern. After you got that down, I think you're safe. Also, feel free to contact me if you have any questions if you have problems implementing. Happy to help.

Jomiro: Cool, I will obviously link your LinkedIn profile so anyone can reach you via there if they have those questions. And, as a last point, what's the most exciting thing for you as a product developer about this pattern in particular?

Christian: It makes coding more fun.

I've always seen coding as like playing with Lego. So, the simpler the blocks, the more potential you have. The simpler you can keep things, the more you can think about your actual code, and the less mistakes you'll make.

So that's also why I think this combination with TypeScript is so powerful because you make less mistakes, you get better. You get better code. As simple as “Oh, it's more fun to work with and also easier to transfer to other people.” I've worked with this on a team. And it was much nicer because they immediately understood the code.

Jomiro: I really, really like the analogy of writing code being like playing with Lego. I certainly had a similar experience, and I didn't even realise it. Just with the few instances I've had playing around with code, I think Lego is a really good analogy for that. That's really really cool. That's fun.

Christian: Yeah, I don't want to oversell this pattern, right? I mean, it's not like it's doing something radically new. It's just a combination of some things that allow you to write simple code.

[27:12] Jomiro: I think what's great about this pattern, though, is it sort of speaks to the possibility of simplifying things yourself. Like, if something is overly complicated, that it doesn't necessarily have to be like that.

And there are patterns, really good patterns, out there, and there are even opportunities to create your own patterns if need be, but you don't have to feel like this is the only way. I think this kind of experience you've had is a really good catalyst for that kind of thinking and I think that's definitely the value — and, as you said, it comes with a caveat or a disclaimer that it really depends on what it is that you want to do. Because, in some cases, Redux might be better, Flux might be better… In some cases, the DAN React pattern might be better. But just to sort of know that there are options.

And yeah, and I think your advice is really good, you know, it starts with something small, see the changes that makes, and then decide if you want to scale those impacts on to a bigger project or maybe, as your team is going to do now, across your entire website. But I think that sort of thinking is really really useful.