Brilliant new search algorithm AWS. Cloud Formation comes in 3rd when searching for “cloud formation”. It actually comes in second until you finish typing the word “formation”, then it moves down a notch.
My first web programming job ever - I made up a search algorithm that I swear is superior to 90% of what’s out there now. The whole product DB was driven by a spreadsheet - with multiple levels of categories, product descriptions, product names, and sub-product descriptions and names.
I came up with a scoring system where product name matches got more points than descriptions, secondary category got more points than parent category, etc. - and most importantly full word matches got double the points of partial matches. Sort by most points. It never ran into issues like this. I was so proud of that search. I never once saw it delivered weird results like this.
It took like 5 minutes of thought to come up with that system. I bet these guys get so hung up on their bubble sort and infinitely more complex algorithms - they miss the forest for the trees.
Of course AWS might be deliberately trying to promote more profitable services over boring standard stuff. But still - when I type the exact thing (minus a space) it damn well better show up first.
While I’m on a roll - this is the shit a lot of people don’t get when hiring imo. I used to work with a guy who wasn’t the greatest front end dev ever. But you could count on him to never let something like this happen. He rose very high in the company leading projects. It’s just basic common sense. Tech companies discount that stuff because they cant test for it in an interview. But everyone knows the people in the company who can be counted on to deliver a good working product that doesn’t have dumbass mistakes - even if they weren’t explicitly spelled out in the requirements.
My current front-end lead drives me nuts doing stuff like assuming the app will always land on a certain page after login. Oh shit we want to sometimes land on a different page? Complete redesign because that one page also triggers the header to re-render to logged in state. He just told me that he has to completely redesign the react routing flow to send users to the home page instead of login page after they logout. He’s a very knowledgeable technical developer who would probably pass a technical interview with flying colors. Basic common sense/seeing the forest for the trees - might be a bit lacking though.
Our leadership has decided that the plan to lower the amount of cases in the inbound queue is to, checks notes, assign 5 to each person… I was wondering why all my managers were named Peter…
The new one is when a user logs on the following happens:
semi-transparent loading screen goes up
through loading screen you can see the header change to logged-in state where Login button changes to user’s initials
header changes back to non-logged-in state showing Login button again
header changes back into logged-in state showing initials
loading screen goes away
The dev agreed to fix it by removing the Login button during login. But to me this is just a sign some wonky stuff is going on in the background.
I still don’t understand why the header can’t just be driven from a binary state - logged in/not logged-in. But somehow in both sites this guy did, getting the header to display properly and re-rerender when you want it to is a gigantic mess that he swears there’s no way around.
My point is that I doubt you catch this in a technical interview. He knows all the gizmos and how to use them. It’s using them together in a reasonable way that seems to be a problem. He just gets so wrapped up in thinking a certain way, that he seems to have a hard time backing up to see the forest for the trees.
Yeah that’s what I think. But I’m not a react wiz.
So the basic problem is that we don’t seem to have some kind of global state that when you change it, the header immediately redraws. How is this normally handled with react sites? Like it would be perfect if the header could just watch localStorage - then react when a logged in user is stored or deleted.
In website #1 - he assumed the user would always land on the main landing page after logging on, so that page drives redrawing the header. Well naturally users would like to click a link to a different page in the site which requires login, be redirected to login, then sent on to that specific page after login. So for now we have that damn function to redraw the header on 4 pages. Definitely terrible. But we’re going to redo the site soon so whatever.
All this was supposed to be fixed on Website #2 through the magic of react hooks. So now he’s driving everything from useEffect which constantly fires, even in cases where you’d really just like it to fire once on page init (like the old days when we passed props and did something on componentDidMount). So what’s happening is one component is thinking the user is logged in, but another component hasn’t realized it yet, then finally it does. I think.
We also have a problem with logout on site #2. The site logs the user out, whereupon the main landing page immediately detects the user isn’t logged in and redirects them to the login page. The problem is if the user explicitly logs out, we want to send them to the home page, not the login page. For some reason the fix for this was super complicated (everything is always super complicated) and required something called protected routes - which then introduced the login button reappearing problem on login I mentioned. I actually had a fix that redirects the user to the home page first, then logs them out. But he didn’t like that.
I feel like we’re back in the old angular 2-way data binding web of events all triggering each other multiple times with weird results.
No to both. Might be part of the problem. To be fair the dev I’m talking about wasn’t on board at the beginning of site #1. A contractor did that who was supposed to do redux but basically did nothing. I had to take over for him.
Site #2 otoh is the lead dev’s baby. And it is soooooo complicated. Every gizmo you can imagine. That’s why I think this dev would nail the standard technical interview. But somehow it never occurs to him that the user might want to go somewhere other than the login page after logging out.
Actually all of login/logout/signup/change password he kind of inherited from site #1 and mostly just ignored. Somehow we got all the way through our “QA” testing w/o anyone even trying social login. Which was totally broken. Everyone was so focused on features they just assume non-standard login/signup worked. (Obviously we don’t have a real QA team.) Login - not sexy, but if it’s messed up the users will totally lose confidence in your site.
Auth is done through amplify library which hooks up to AWS cognito. The test for whether the user is logged in is something like await Auth.getSession(). It throws an error if the user isn’t logged in (either no token or token over an hour old, or the user explicitly logged out and we clean out localStorage where amplify stores the jwt tokens).
So in your world where would you put this try/catch block? And then you would save the result in context, and wire up the header to the context? Just making sure I have the basic idea right. I’m going to try it on site #1 - which I mostly own now.
The site is static react served from S3/cloudfront. There is no sever-side user session - only jwt tokens provided by Cognito, which the amplify library keeps in localStorage. How would index.html served from S3 know if the user is logged in?
The main difference to me with hooks seems to be you don’t have to pass props down multiple layers of nested components. Which can be a pain, but also makes the code a lot easier to reason with. Hooks feel more like events to me, which are super hard to debug when they get complex. Or maybe I’m thinking of his other change - wrapping everything in various contexts so it naturally bubbles down to every subcomponent.
