YosepRA posted: " When I first designed PetTake, I thought I won't need to make a login and register page (auth pages). I really wanted to use a modal window at the time, and I got it working by simply using Bootstrap's modal component. That was the case until I come "
When I first designed PetTake, I thought I won't need to make a login and register page (auth pages). I really wanted to use a modal window at the time, and I got it working by simply using Bootstrap's modal component. That was the case until I come to add protected routes to the UI. That is pages that will be protected by authentication state. Basically I want the users to login first before entering the sacred land. Now if a user is yet to be authenticated and they are entering one of the protected route, I would pop-up the login modal window and urge them to login, wouldn't I? Yeah, not until I realize that the modal control component is pretty much out of reach from the component that does the authentication screening.
What I mean from the control being out of reach is I can't reach its interface to control modal's open and close state. Of course there are many solution to this problem such as using Context to spread the modal controls to those who need it, or even put it on Redux. But for me, that is too much of a hassle for a workaround, and I thought making a dedicated auth pages would be easier. Auth pages it is, then.
The challenge for having multiple components that do the same thing is how you would spread its shared functionality. Would you write the same logic over two components (Login modal and Login page)? Of course not, right? If there is one thing I learned about computer programming is that there shouldn't be any repetition. The computer was invented so that humans won't do boring repetitive task anymore. With that being said, if you notice something repetitive in your code, there should be a better way to write this. Sure there is a limit for universalizing the code, but that's another matter.
One of the way to share functionalities between different components in React is to use Higher-Order Component pattern (HOC). To put it shortly, it's a function that will be given a component as an argument, and will produce another component in return. During building said component, you can insert your functionalities as you see fit. In my case, I'm giving the incoming component an interface to do login or register routine.
The trend of React is to ditch class components and use function component + hooks instead. I still don't see a need to switch to hooks yet because that will probably require me to adapt to a new pattern, which will take time regardless. Besides, React won't be removing class components in the near future anyway, so I wouldn't bother even a bit. One of the complaint about class component in React is actually the HOC pattern. It is said to be confusing and somewhat dirty. I couldn't relate to it prior to today because I'm fine with it. But my experience today in sharing authentication functionalities using HOC gave me a glimpse of reasons why the complaint made sense.
In short, I'm using multiple HOCs to build auth pages and modals. They are: Redux "connect", React-Router "withRouter", and my custom HOCs. That is three levels of HOCs. It's not like I'm confused with the pattern, I just thought that it would be much better if there's a cleaner way to write this. And it is said that React hooks provides a new solution to this problem, which is creating a custom hook or some sort. Again, I'm not yet educated about hooks so I may be wrong. But I'm curious how function and hook can solve this problem.
That's pretty much it. I'm currently building the user dashboard and figuring out the way to deal with cookies, credentials, and Apollo Server to get the currently logged in user. That will be on tomorrow's post, so I'll see you there. Thank you for reading my post and I hope things go well for you.
WordPress.com
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.