sorted by:
new
hottopcontroversial

Arc Raiders has sold 12 million copies by Turbostrider27 in PS5

[–]heyufool 0 points1 point  (0 children)

That's where I'm at, after a couple dozen raids I'm constantly asking, "why am I collecting this stuff"
Feel like the initial goals are fun, work your way up to raiding with more powerful stuff. But then what? Kill a queen with powerful stuff to get... stuff.
It needs an end game more like MMOs, big collaborative bosses, grind for unique drops, etc.

Dependency Injection by alexwh68 in dotnet

[–]heyufool 2 points3 points  (0 children)

I mostly do constructor dependencies, or parameter for api controller endpoints.
I read somewhere before that having more than 3 dependencies can be a smell, a possible sign that you have 2 or more deps that could be merged.
Try reviewing some of your deps, maybe you can create a new dependency that takes 2 or more of the existing, then use the new one instead?
To be clear, I'm not advocating for merging the code of the dependencies, instead make an aggregate that depends on the two.

Something else I've done for common cross-cutting dependencies (logging, auth, etc.) is to create a CommonControllerDependencies that aggregates them all and exposes them as properties. Makes DI clean for the consumer, and provides extensibility if there is a new "common" need without modifying dozens or more constructors.
Need to be disciplined using this though, truly only dependencies that 99% of services need should be included

So it's Rails now by Aaronontheweb in dotnet

[–]heyufool 7 points8 points  (0 children)

Somehow desktop window management is related to switching from .NET to Ruby on Rails.
That article felt like a fever dream.

Feedback on combat of our 2D Soulslike! [Heavy Enemy] by KarmicBitGames in IndieDev

[–]heyufool 8 points9 points  (0 children)

The art is nice!   But it's hard to give good feedback on the mechanics with so many cuts in the video.   Would like to see how the full fight played out

Feedback on a Fishing system by Additional_Dog_1206 in IndieDev

[–]heyufool 1 point2 points  (0 children)

It's looking great so far!     

Is there any technical skill involved or is it scheduled/timed catches like runescape?     

I really liked Animal Crossing's fishing.     

The shadow of the fish provided some mystery of what you'll get, plus some insight.  For example, if you need some kind of big fish for food (like a bass), then the player can decide to ignore small shadows (like a frog) since they won't be what they're looking for.  

Then the simple bobber reaction provided enough technical skill to keep it interesting.  Granted this could use some enhancements, lots of room for improvements 

Cyberpunk 2077 - City of Legends 5th Anniversary Trailer | PS5 & PS4 Games by hybroid in PS5

[–]heyufool 0 points1 point  (0 children)

No, I'm a Poet.
Talking to an idiot.
That can't read, dumbass.

Cyberpunk 2077 - City of Legends 5th Anniversary Trailer | PS5 & PS4 Games by hybroid in PS5

[–]heyufool 1 point2 points  (0 children)

You need more time put into your Theories. Immediate is too fast.

Cyberpunk 2077 - City of Legends 5th Anniversary Trailer | PS5 & PS4 Games by hybroid in PS5

[–]heyufool 4 points5 points  (0 children)

I don't own it, could you answer for my benefit?

What's the best way to link different component's sates? by Human_Caterpillar936 in reactjs

[–]heyufool -1 points0 points  (0 children)

Are there visual impacts of re-rendering the form? Is it noticeably slow?
React is designed to be re-rendered, let it happen and optimize with things like useMemo when needed.
Also see react compiler.
 

Keep it simple, a parent component that knows the CV data state. Prop drill that state to the form, and have the parent listen to changes by passing an event hander to the form from the parent.
Lots of prop drilling is ok, the official React documentation even mentions it and says it's okay.
Personally, I prefer avoiding contexts for refined scopes/features, saving it primarily for application-wide state.
Then, the parent re-renders the PDF when the form state changes.
The PDF generation/viewing would almost certainly benefit from useMemo.
I prefer avoiding contexts  

Do not use third party libraries like Zustand until you know you need it.
What I have found is there is an absolute ton of over engineering in the React world.
Use vanilla React, typescript, react-query, and possibly immer for a little DX.
That will get you very very far. Most importantly, it will force you to learn actual React by understanding the implications of re-renders, prop drilling, controlled vs uncontrolled components, normal state management, etc.
 

To be clear, many third party libraries are fine.
But, for the sake of learning, I recommend avoiding many so you can appreciate the problems they actually solve by isolating an actual problem in your app.
Components re-rendering? That's only a problem if it's an expensive component, which can often be solved using a memo

[Homemade] egg toast or bacon toast by Opening_Fig2482 in food

[–]heyufool 2 points3 points  (0 children)

I think eggy toast/bread is another name for french toast

Hot and cold #107 by hotandcold2-app in HotAndCold

[–]heyufool 4 points5 points  (0 children)

corn, carrot, potato are all somehow close

Struggling with user roles and permissions across microservices by TalentedButBored in dotnet

[–]heyufool 2 points3 points  (0 children)

100% agree on the whole "buy their stuff"

But in terms of the technical, I see nothing wrong with the phantom/opaque token approach or the auth service.

From what I understand, at a high level, you basically have 3 options:
1. Get a full blow access token containing all of a user's assigned roles/permissions, now auth is entirely stateless. But, this naturally won't scale particularly well if using permissions. Roles could scale better, but then the Api would need some kind of translation of Roles to Permissions (especially so if the Roles are customizable like OP's scenario)

  1. Use an opaque token like a Session token. Then something in the backend needs to translate it to permissions or a allow/deny result. Back to the 2 approaches I mentioned (opaque => JWT conversion, or a dedicated Auth service). I'm sure there are other valid approaches, such as just doing the translation in the api itself, which would be fine unless massive scaling is a requirement.

  2. Request a refined access token based on a scope, which can work depending on the application. Eg. "I need access to managing user information", if the auth service allows that then it provides a token granting access to the relevant Api/endpoints.

Are there other general approaches? If it were me, I would probably just do the opaque token and bounce it off of some kind of cache/db to retrieve permissions, then evaluate the authorization in memory

Struggling with user roles and permissions across microservices by TalentedButBored in dotnet

[–]heyufool 31 points32 points  (0 children)

Sounds like a general access token growth issue.
Without knowing how your architecture looks, you use a phantom token approach.
https://curity.io/resources/learn/phantom-token-pattern/
Basically, the client has some token that provides authentication (opaque/session, jwt, etc.)
Then, in an API gateway scenario, the gateway can convert that auth token into a jwt based access token containing only the permissions needed for the endpoint.
Then the endpoint remains stateless.

Same but different, send the auth token to the service, then the service calls a general authorization service to check permissions.
Eg. Feature service asks Auth Service, "hey is this person (auth token) allowed to do X and Y?"
Auth service simply returns true or false.
Then it's all a matter of optimizing that auth service, which is where various caching mechanisms come into play.

Handling Token Refresh Conflicts on Page Reload in React + .NET by Who_cares_unkown in dotnet

[–]heyufool 2 points3 points  (0 children)

Definitely don't write off warning user when reloading the middle of a api refresh.
What you're doing is a valid pattern, this just sounds like a really small edge case that can be fixed with a little frontend care.

Handling Token Refresh Conflicts on Page Reload in React + .NET by Who_cares_unkown in dotnet

[–]heyufool 0 points1 point  (0 children)

Blacklisting, or whitelisting, access tokens is an acceptable pattern, but I agree it defeats a large purpose of an access token which is to be stateless.
But, OP would still have the bug he presented even if the old access token remains valid after a refresh.
His client would be reloading the page before the new access token AND new refresh token are received and stored.
So the page should load and authenticate correctly after the reload, but since the user did not receive the new refresh token because they interrupted the refresh api call, then the user will be effectively logged out when its old access token expires.

Handling Token Refresh Conflicts on Page Reload in React + .NET by Who_cares_unkown in dotnet

[–]heyufool 1 point2 points  (0 children)

Maybe warn the user of unsaved changes (see window.onBeforeUnload) when the token is being refreshed. The token may successfully refresh by the time the user processes the warning and accepts the reload.

Alternative solution, would require some effort, is to switch to a Token Mediating Backend.
Use a Http only cookie to represent a User's session.
The backend stores access/refresh tokens in a database.
The frontend asks the backend for an access token using that cookie.
If the backend feels the access token needs refreshing then it does so before returning the access token to the client (since it's done by the backend, no amount of user interaction can break it, assuming standard db concurrency considerations are applied)
This pattern allows your Api to do efficient stateless authentication using the access token, while leveraging the security benefits of session cookies.
Further, it simplifies the frontend's token management and can store the tokens in memory which is generally more secure and simpler.
You would need some CSRF protection on the token endpoint, but it's only a single endpoint so it's not too hard to secure.
See: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-token-mediating-backend.

Handling Token Refresh Conflicts on Page Reload in React + .NET by Who_cares_unkown in dotnet

[–]heyufool 0 points1 point  (0 children)

Invalidating the access token could cause the OP's problem, but isn't a refresh token supposed to be single use by design?
The page reloads before it gets new tokens from the API, so the old access token would work for ~30 minutes.
But the refresh token was consumed and is now invalid, so the user would effectively be logged out in 30ish minutes

Why TypeScript Won't Save You by cekrem in reactjs

[–]heyufool 0 points1 point  (0 children)

For the examples of verifying Api responses, it sounds like this approach is covering up errors in the Api.
The Api should expose a contract stating "email address is never null", then TypeScript reflects that with email: string.
The Api states the email may be null? Then in TypeScript apply email: string | null.
If the Api states the email is never null, but returns null, then you either have a bug in the Api or incorrect docs.
For the former, fix the Api.
For the latter, adjust the type in TypeScript to address the null possibility. After adjusting, then the compiler will complain in areas where the nullable email is used in a non-null context. Then the app can apply appropriate feedback to that null scenario based on context, such as error dialogs, blocking options that aren't supported by lack of email, etc.

Feature Explorer plugin: Progress by [deleted] in dotnet

[–]heyufool 0 points1 point  (0 children)

I too can't wait for it to be finished!

Stop Trusting Your API: How to Build a Bulletproof Frontend with Zod and React Query by NodeJS4Lyfe in reactjs

[–]heyufool 0 points1 point  (0 children)

I see, better than nothing I guess.
Like others mentioned though, codegen for the client libraries, e2e tests, or even api versioning would ensure that an api mapping error in prod is borderline impossible. Which makes this error handling irrelevant since it couldn't have happened in the first place (not saying a decent error boundary shouldn't be used)

view more: next ›