angelguzmaning / ts-redux-react-realworld-example-app Goto Github PK

First of all I want to say that it is an excellent job , thank you for this contribution, I find this approach very interesting and I try to integrate it into an NX project.

while browsing the code I was wondering if there is a particular reason not to have used selector and the hook UseSelector instead of useStore as pattern.

https://redux-toolkit.js.org/usage/migrating-rtk-2

Hey @angelguzmaning, I couldn't find your contact info so I figured I'd just open an issue.

I teach engineers how to do DevOps (setting up CI/CD pipelines, on-call rotations, monitoring, etc). I'm putting together a free video to show engineers the modern way of deploying and monitoring software. Instead of making my own example app I'd love to use this as a demo. I couldn't find the code license anywhere, are you ok with me doing this?

If you're not, that's cool! I was just really impressed with all the modern best practices you've done here.

I have a question about the conduit.ts file in /services. Taking updateArticle and getArticle as an example, some of the functions in this file omit try/catch's. Is it to obfuscate back end failure from the front end - i.e. the only errors we care about are errors that were caused by sending data from the front end? I see that the only places that have try/catch's are where axios is receiving a second argument, for the most part. There are 1 or 2 exceptions to that pattern I’m seeing.

wondering about the reasoning for omitting try catches on some of these? or if you have any resources to read more about this?

In short, why wouldnt you always use a Result type and thus a try/catch scheme, at least for the sake of consistency within this file?

thanks!

Hi, I wonder if when I work on 2 different functions but use the same GenericForm.tsx and FormGroup.tsx, how could I set the validation for one function but not in the other. Or I just create another GenericForm and FormGroup for my own purpose.

when I run npm test -- --coverage, it get zero coverage result.

my node version : 14.16.1

Hello!

Due to governance changes, we are now using the realworld.io domain for the RealWorld demo (both client and API).
Requests from conduit.productionready.io are redirected to api.realworld.io, but such a redirection might lead to inconsistent responses.

We encourage domain change for the community.
If this repository is maintained anymore, we'll consider hosting a demo of your implementation in a few weeks with the domain change.

The demo link will be added to the RealWorld documentation.

Could you please add the LISENCE.txt.

I tried to play around this project.
It is awesome that you used typescript and decoders to check the data's type.

however, when the axios's request get a non-200 response, it also raise an error, then the data destructing for {data} will not work well.

I assume the purpose of try catch ({data}) {} is only used for catch the error from guard, is it right?

do I need to do something like this to handle the error ?

export async function login(email: string, password: string): Promise<Result<User, GenericErrors>> {
  try {
    const { data } = await axios.post('users/login', { user: { email, password } });

    return Ok(guard(object({ user: userDecoder }))(data).user);
  } catch (error) {
    if (error.response.status != 200) {
      return Err(guard(object({ errors: genericErrorsDecoder }))(error.response.data).errors);
    }else { // error from guard
      return Err(guard(object({ errors: genericErrorsDecoder }))(error.data).errors);
    }

    //return Err(guard(object({ errors: genericErrorsDecoder }))(data).errors);
  }
}

or do something like this ?

 await axios.post('users/login', { user: { email, password } }).catch(function(error){})

how do you think? what is the best practice to handle the errors?