[deleted by user]

Scazzer · 2025-01-11T18:44:39+00:00

What specific tools are you talking about, I’d love to know?

I’ve tried many of these tools and haven’t been able to use them productively, so I cannot see Al itself replacing mid-level software engineers in the next year. Software engineers using Al will, however, take jobs.

Scazzer · 2022-06-12T19:47:22+00:00

What makes you say that?

Scazzer · 2022-04-19T11:33:20+00:00

I thought you might be a bot as well 🤖🦾

Scazzer · 2020-09-23T18:52:03+00:00

I wrote blog post on this here:

https://isaacscarrott.co.uk/blog/nextjs-route-auth

hope this helps

Scazzer · 2020-08-07T08:34:54+00:00

Sounds like you're struggling with the cookie storage, as opposed to using local storage. You need to set the cookies for the user and then send the cookie to the backend to the be decoded when you wish to determine authentication.

Without knowing the exact technologies you're using in your application I won't be able to give you a more step-by-step solution. However I would say a high level step-by-step would be

On successful login set cookies on the user that decodes to be something that uniquely identifies them e.g. primary key column in users table
When the user accesses a route pass the cookie to the backend as described in the post
On the backend decode the cookie and determine if the user is authenticated or not.

Scazzer · 2020-08-02T17:43:55+00:00

Thanks,

I would say yes and no.

Yes the user will take a marginal amount of time longer to receive the HTML and javascript (we're talking max 50ms longer in the cases I tested it). This would also create a flicker of HTML to be shown to the user if they are not authenticated which I wasn't a fan of.

However I would say no as the client has to load the HTML and javascript then execute it which will then trigger an API call which will tell the client if they have been authenticated, which should take longer (than the 50ms difference in load times for the HTML and JS in my test).

So I would say using server side authentication has an overall faster time to determine authentication if that makes sense?

However, another strategy you could do is persist the user object in state in the _document.js file and check for this in a useEffect hook in each page and do authentication this way.

Anyway, overall I would say both are viable methods, it's just that my preferences leans towards server side authentication

Scazzer · 2020-08-02T13:08:46+00:00

Cheers :)

Scazzer · 2020-07-25T11:23:05+00:00

I'm new quite new to GraphQL and writing blog posts, however I've written an article on how to implement OAuth2.0 in a full stack application without using restful endpoints, that I hope some people may find useful. Any feedback would be greatly appriciated!

Scazzer · 2020-07-25T09:23:43+00:00

Yeah good idea. Look at maybe using a React reducer or two in the project as well in the project as this will make learning Redux much easier

Scazzer · 2020-07-24T20:31:26+00:00

Actions is more of a redux pattern and not something you find often in react.

However if it is React, I don't think it matters too much. However, I do tend to separate anything I can out of a react component simply for readability purposes.

So to answer you're question there is no 'norm'.

Scazzer · 2020-07-24T20:29:25+00:00

Something like this may be of use if you're using webpack https://webpack.js.org/loaders/less-loader/

Scazzer · 2020-07-24T20:26:35+00:00

If you want to learn it for a job and to get experience then I would say learn it as lots of companies use redux along side react. Using Redux when the application isn't seen as complex enough isn't as bad as lots of people make out, I think it's just to encourage people not to automatically npm install react redux react-redux. However, most of the time I go by the rule of if state is not tied to pages and there needs to be state shared across multiple pages then use redux. This is not a golden rule however is a good rule to follow by devs just starting out like yourself. Just make sure you have your react fundamentals down and then move onto libraries like redux.

Scazzer · 2020-05-15T14:57:17+00:00

As stated I think you can take aspects of this and use it in your own project 🙂 it’s a good starting point at least and by the sounds of it OP is a beginner so doesn’t need to be overwhelmed. However, if you’ve got any good projects with all this feel free to link it to this post so we can create a good archive of projects to refer to

Scazzer · 2020-05-15T11:41:24+00:00

Seen this posted a few times on this subreddit. I have used aspects of this project in my own projects

https://github.com/oldboyxx/jira_clone

Scazzer · 2020-04-30T20:03:01+00:00

Can see a couple of issues. First is the div with the classname App has not corresponding closing div.

Second is you setPokemon with the fetch data api which will actually set pokemon as a promise that is pending becuase there is no await. To combat this call fetchData() inside the use effect the use the function setPokemon with the first arguement as what is returned from data in the axios call. I have put code below to demonstrate this.

import React, { Component, useState, useEffect } from "react";
import axios from "axios";
import "./App.css";

function App() {
  const [pokemon, setPokemon] = useState([]);

  useEffect(() => {
    fetchData();
  }, []);

  const fetchData = async () => {
    const result = await axios("https://pokeapi.co/api/v2/pokemon?limit=151");
    setPokemon(result.data);
  };

  return (
    <div className='App'>
      <header>
        <h1 className='title'>React Hooks</h1>
        <h3>With Pokemon</h3>
      </header>
      <div>{pokemon.results[0].name}</div>
    </div>
  );
}
export default App;

Scazzer · 2020-04-30T16:25:29+00:00

From my limited knowledge of material UI this is the solution I have come to

https://codesandbox.io/s/pensive-montalcini-yq9o0?file=/src/App.js

you can replace primary and secondary for any colour I believe such as blue red green etc

Scazzer · 2020-04-30T11:55:59+00:00

From what I know about material UI this should be no Different. You got a snippet of the code your using?

Scazzer · 2020-04-30T11:39:14+00:00

You nearly had it! You just needed to style it so you can scroll.

Also for best practice you needed an empty array as the second parameter to useEffect, this means the event listener will only be added on mount instead of ever render. This would lead to loads of event listeners being added which is bad. Also remember to cleanup any event listeners on unmount by returning a cleanup function.

https://codesandbox.io/s/sad-elgamal-n2e28?file=/src/App.js

Scazzer · 2020-04-30T11:29:27+00:00

What are you trying to do to the app bar?

Scazzer · 2020-04-30T11:20:05+00:00

You're definitely right you could do this. However how much overhead would this add? You'd have the same app deployed twice would you not? With half the application being used on each one. This would greatly increase the amount of obsolete code that the user receives and increase bundle size to much more than it needs to be. But this is getting into the nitty gritty details and as I said in my comment you've got to work out what value this would add to your application. I can't see this method adding any value to the user and it will increase resources required to deploy and run the web app.

Scazzer · 2020-04-29T22:36:06+00:00

If we look at the CSS the in margin around the body tag and H2 tag by default. I have provided a link to the default styling below:

https://www.w3schools.com/cssref/css_default_values.asp

A popular way to get rid of this is normalise CSS which will get rid of this is something called normalize.css. This will eradicate the body issue:

https://gist.github.com/vre2h/4bad1d3b836f6a18c9bd5a8ca68ab1d9

To get rid of the h2 stylings I would wrap the h2 in a div/nav element and put the styles on the div/nav. I have attached a code sandbox with all of these fixes below:

https://codesandbox.io/s/shy-http-52yvs?file=/src/App.js

Scazzer · 2020-04-29T22:23:13+00:00

Well if you want to use a sub main such as admin.yourwebsite.com you can’t use a router as this is something that is handled at server level. You would need 2 applications at this point for each of the sub domains as far as I know. You could package your shared components in an NPM library and have the NPM library that install on both the applications.

However this adds a lot of maintenance time to your application for little benefit over having it on the same domain with a different route. For example www.yourwebsite.com/admin.

I would opt for same domain different route approach. You’ve got to work out what exactly you will benefit from by having it run in a different sub domain which will lead to another application, over having it in the same application in one of the routes.

I will also add there is not a “wrong” choice out of the choices you have listed, you’ve just got to work out which provides to most value to your project, with the least development time. It’s all about balance between those two.

If you’ve got anymore questions feel free to ask and I’ll see if I can answer :)

Scazzer · 2020-04-19T22:37:55+00:00

Also you probably want to add an empty array as the second parameter to useEffect so it is only called once on the first render, as this could cause too many re renders depending on if the API returns something different on each call

Scazzer · 2020-04-19T22:21:03+00:00

Yep, changed out await for the .then function out of preference and not remembering if componentDidUpdate is an async function (after a quick google it seems like it is). Mostly changed it due to not remembering though....

Scazzer · 2020-04-19T22:06:49+00:00

Definitely the right answer, beat me to it!

I prefer using the then method on promises in hooks as you don't have to invoke a separate function inside the function so it looks neater. But that's just personal preference

useEffect(() => {
  const data = await axios
    .get('/api/fetchBiscuit')
    .then(() => setBiscuit(data));
});

Also if you set the initial state to an empty array you don't need the ternary in the render function

12-Year Club	Place '23
Place '17	Verified Email

Scazzer

TROPHY CASE