Ash TypeScript: Rich Phoenix Frontends, Simplified
Code and Stuff
YouTube
Ash TypeScript: Rich Phoenix Frontends, Simplified
In this video, I explore Ash TypeScript, a new library that automatically generates TypeScript client code from your Ash resources.
We'll build a stock explorer app using SEC data to demonstrate how this eliminates the complexity of designing APIs and building client libraries when you need JavaScript frontends for your Phoenix apps.
What's co...
36 Replies
LFGGGGGGGG
Watching soon ❤️
I think the nested load not passing your types might be a bug actually
@Torkan around minute 40
I’ll check it out tomorrow! 😅
Well done!! I watched on 1.25 since I'm in the car 😆 no popcorn for me this time 😭
Yea sorry for the bug report via video 🙃
Haha all good
Means we have a fun update to post once fixed haha
Storytelling and engagement!
There’s always round two!
Actually @Christian Alexander, the reason you're not getting autocomplete on the exchange, is because the exchange resource isn't exposed in the rpc block 😅
You're getting the data since there is no policy blocking you from seeing it
We need both a better api and docs around this, open to suggestions, there are probably some conventions we should follow as well, maybe use the same pattern as ash_graphql with requiring resources to use the AshTypescript.Resource @Zach? Then we can reject any loading etc of resources that are not exposed entirely
Honestly I loved how easy it was to access the data, in the same way I’d be able to from the Elixir side. I bet it would be hard to determine which fields and relationships are public, but it’d be incredible if that was the trigger for field type generation
But if more ceremony would lead to a more secure system, I’d understand
Yeah @Torkan it should have prevented loading anything who's destination didn't have a type configured
or wasn't in the RPC I mean
good call
Posted the video on the orange site btw
Yeah, ok, let’s do it the same as ash_graphql et al
Thank you @Christian Alexander 🙏🏻♥️
lol let’s see how much hate I get for throwing shade at Node backends
Awesome video btw, forgot to mention that! 🙈❤️
Its hacker news, hate abounds
Sorry for subjecting you to it lol
Haha no such thing as bad publicity
Shouldn’t be that much work to short circuit the code generation for relationships that link to resources that aren’t exposed fortunately
I think the code already isn't generated
right?
Yeah sorry, I meant the loading 😂
By the way, YouTube is rolling out a new feature called Hype. Most users get 3 hypes per week, and it really helps new videos get discovered. If you have some hype points lying around, I’d appreciate your vote
Hm, I looked around in the mobile app now, but I didn’t see anything about that feature, probably only out in the US for now?
hyped it thrice
I’m not sure where they’re at on the regional rollout, but thanks for looking!
The Zach so nice, he hypes it thrice!
Sorry i think it is not active out of US, i tested with island VPN, it is not active
No hype to give then 😭
Ok, I've pushed a fix to main now for this, it'll give an unknown field error if you try to load a relationship that is not using the AshTypescript.Resource extension
I suppose I’ll have to update the demo repo now that it’ll be broken on the latest ash_typescript.
I get why it’s preferable to have it defined in the resource, but it definitely adds complexity.
Yeah, that's a bummer
But the sad part of life with immature libs
I think it’s an example of the friction between rigid structures and desire paths, and an application of Hyrum’s Law
Yeah, we already have existing conventions in place as well, so overall it's most likely better to have them all behave as similarly as possible
But I do see the argument that this could be viewed as a policy thing though
Is there something special that has to be done to resources for regular Ash code interface functions to load related resources and fields?
Or is the existing convention more around extensions like the JSON API and GraphQL libraries?
I'm sure the others in the core team has chewed on this dilemma quite a bit already, I guess there are just as many arguments both for and against just letting policies be the single source of truth
No, if you're on the "inside", it's just the policies that will deny you access
I'm assuming that at some point someone wanted to be able to say "we just want to expose these things and only these things through this external form of communication with our system", anything else should never leak
Totally, I thought that’s what public was for
Yeah, for fields that is always respected, there is no similar functionality for entire resources though
public? exists on all relationship DSL options I could find (belongs_to, has_many, has_one, many_to_many)Ah yes, I meant even outside relationships, more like that resources themselves don't have a similar feature to public? for attributes
And then there was probably a need for "we want these things to be accessible through our internal json api that is for admins, but not graphql which is meant for public consumption" etc
Zach or any of the others that have been around the block a bit longer than me, can probably give some good reasons for how it came to be this way 😅
Ok, pushed the last thing now that is required for this to work, which is a verifier that all resources using the AshTypescript.Resource needs to pick a unique
type_name as well
Another thing that is also coming soon, is the option to expose a resource field under a different name, which is needed if a field has a name that cannot be used in Typescript, for example a calculation with the name is_admin? on a User resource, which is allowed in Elixir but doesn't work in TS
That doesn't affect your demo though fortunately 😅The reasoning behind this is that it's one thing to decide to expose a resource and its fields
And another thing for "adding one resource to an interface" to implicitly also add its entire graph of public relationships
So the pattern is always "all public fields, and all public relationships whose destination is also explicitly added to this interface"