>"this is perfectly readable when compared to even more unreadable garbage like c++ templates"
typical midwit take
>Retard tier: Can't read it >Midwit tier: Can read it and think this is an accomplishment in itself >Ascended tier: Can read it and identifies how extremely flawed it is
>types are so dog shit the author cant debug it >re exports the function with :any to make it work
kek, based. bet the codebase is also littered in //@ts-ignore
yeah this is heavy on generics but completely readable.
SS refers to the return type of storeSetup
the options you pass have to match the type of the object you return in storeSetup.
so roughly, if you call defineStore("x", () => {thing: 1}) then the options argument needs to have only the key "thing" in certain places.
it then returns and object which lets you modify the options later, with the same restrictions.
and then because there's an alternative set of arguments the implementation uses any (this is *probably* to prevent breaking changes. it's not great, but the libraries have to choose between breaking code or being slightly weird)
[...]
what exactly is this supposed to do
it creates a Pinta store, i think. Pinta is used maintain a history of application state so you can go backwards, or reload from a serialized state.
I mean this is readable but so many on this board say >this rust/haskell/functional code is readable
and it's just a flaming pile of shit with stuff like >_ExtractStateFromSetupStore<SS>, >_ExtractGettersFromSetupStore<SS>, >_ExtractActionsFromSetupStore<SS>
Why not make code pretty and simple rather than freaky penis in asshole shit like this?
for starters FromSetupStore isnt necessary in the type names since its obvious where you are getting it from in the typehint. The underscore to represent some private type is a callback to some poor workarounds in javascript and php. The code is pessimistic, and its so bad that it doesnt even get used, the author re-exports the function with :any types.
>FromSetupStore isnt necessary in the type names since its obvious where you are getting it from in the typehint
It's a type defined in an other file, and this isn't the only place where those are used. >The underscore to represent some private type is a callback to some poor workarounds in javascript and php
It uses an underscore to indicate it should be exported to the library user. Again, you're not providing alternatives. >The code is pessimistic, and its so bad that it doesnt even get used
It is used, the result is shown in
How would you write it then? Keep in mind this is for a library used by users that aren't (you), so no >I just memorize all the types
. The reason the implementation uses :any, is because that function has a lot of overloads.
lol his tiny janny pecker got hard typing this
>janny
Anon, that is THE guy that created vue.
At the point where you're asking for an options that contains three functions that "extract state from setup store", "extract getters from setup store", and "extract actions from setup store". You have left sane programming behind. These people need golang.
>These people need golang.
Doesn't run in the browser.
So, move verbose jsdoc doing the same thing, or no nice ide support for end users?
2 weeks ago
Anonymous
It means ditching the concepts of "setup stores" "actions getters" and "getter getters" and all this junk and actually just telling the computer what you want to do. Something the JScel cannot understand.
NOOOOOOOOO you can't do that, use my 50 nagger store objects, built with a function that returns a function tha needs 3 more objects with getter, setter and a bucnh of bullshit.
2 weeks ago
Anonymous
just use classes. all IDEs support code completion for those and you can generate a d.ts file without even using jsdoc annotations. javascript has types built in if you use classes, the shit in the OP only happens if you are attaching or inferring or mapping types from object literals.
>DefineSetupStoreOptions >ExtractStateFromSetupStore >ExtractGettersFromSetupStore >ExtractActionsFromSetupStore >storeSetup >defineStore
Why??
Why not "setupStore" instead? Why they cannot keep with their own naming convention?
>Retard tier: Can't read it >Midwit tier: Can read it and think this is an accomplishment in itself >Ascended tier: Can read it and identifies how extremely flawed it is
>Is this not hard to be unreadable or not? Yes | No
Lol I fucking hate jeets so much.
But the Typescript is fine, it's obvious what it does if you've seen C++ templates and plain javascript.
Readable it is. But not in the sense of understanding what it does.
I think it is retarded and ugly.
Aliasing a string is useless.
Then it is receiving a procedure as parameter, which might cause side effects.
And the options parameter is just atrocious. Too much abstraction for something that would be clearer in imperative style.
>Then it is receiving a procedure as parameter, which might cause side effects.
Are you having a laugh? That's called a dependency injection. That's an actual DI, not a service registry which is commonly wrongly called DI.
I pray every day for WASM to become a first class citizen on the web so we can get an actually good language to replace TS/JS.
Preferably something with a similar syntax to TS (minus the baggage), but types are real and available at runtime (like on C#) and with typed Enums and match (like Rust).
Perhaps we could find a middle ground where the browser would have a GC the language can use, even if it's only for languages created for being used in WASM exclusively.
[...]
Nobody cares.
2 weeks ago
Anonymous
Then the wasm blob would have to somehow flag the browser gc what pieces of memory can be discarted as a lang agnostic gc cannot figure it out own its own, this would be a nightmare
this is ugly but only because the authors are unable to use typescript properly >breaking backwards compatibility in order to improve the library
based
just stop updooting if you don't want that
At the point where you're asking for an options that contains three functions that "extract state from setup store", "extract getters from setup store", and "extract actions from setup store". You have left sane programming behind. These people need golang.
By the way, that wasn't even the whole thing:
export function defineStore<Id extends string, SS>(
id: Id,
storeSetup: () => SS,
options?: DefineSetupStoreOptions<
Id,
_ExtractStateFromSetupStore<SS>,
_ExtractGettersFromSetupStore<SS>,
_ExtractActionsFromSetupStore<SS>
>
): StoreDefinition<
Id,
_ExtractStateFromSetupStore<SS>,
_ExtractGettersFromSetupStore<SS>,
_ExtractActionsFromSetupStore<SS>
>
export function defineStore(
// TODO: add proper types from above
idOrOptions: any,
setup?: any,
setupOptions?: any
): StoreDefinition {
let id: string
let options:
| DefineStoreOptions<
string,
StateTree,
_GettersTree<StateTree>,
_ActionsTree
I can read C++ and Haskell, this is nothing.
Also this. C++ templates get way more complicated than TypeScript generics because of SFINAE and reference semantics and template value parameters.
Haskell is one of the easiest language to read as long as there are few do-blocks and they stick to a concatenative style.
it's readable. you just don't use a language with generics.
Seems fine to me
Maybe programming isn't the job for you
what exactly is this supposed to do
increase abstraction by 1
define store
>any
Should've just used JavaScript at this point.
>"this is perfectly readable when compared to even more unreadable garbage like c++ templates"
typical midwit take
>types are so dog shit the author cant debug it
>re exports the function with :any to make it work
kek, based. bet the codebase is also littered in //@ts-ignore
Stuff like this helps me understand why DHH shitcanned TypeScript
It’d make more sense if I knew what an SS was supposed to do
t. started on C++98
It's supposed to provide security for party meetings, but if you add enough generics it can do cool things like genocide.
yeah this is heavy on generics but completely readable.
SS refers to the return type of storeSetup
the options you pass have to match the type of the object you return in storeSetup.
so roughly, if you call defineStore("x", () => {thing: 1}) then the options argument needs to have only the key "thing" in certain places.
it then returns and object which lets you modify the options later, with the same restrictions.
and then because there's an alternative set of arguments the implementation uses any (this is *probably* to prevent breaking changes. it's not great, but the libraries have to choose between breaking code or being slightly weird)
it creates a Pinta store, i think. Pinta is used maintain a history of application state so you can go backwards, or reload from a serialized state.
I mean this is readable but so many on this board say
>this rust/haskell/functional code is readable
and it's just a flaming pile of shit with stuff like
>_ExtractStateFromSetupStore<SS>,
>_ExtractGettersFromSetupStore<SS>,
>_ExtractActionsFromSetupStore<SS>
Why not make code pretty and simple rather than freaky penis in asshole shit like this?
>t. dynamic type kiddie
It's called type safely. You'll love it when you grow up.
you're messing up the dichotomy.
one can have a strong, statically type checked system while also foregoing manifest typing
what exactly is bad about that?
How would you write it then? Keep in mind this is for a library used by users that aren't (you), so no
>I just memorize all the types
for starters FromSetupStore isnt necessary in the type names since its obvious where you are getting it from in the typehint. The underscore to represent some private type is a callback to some poor workarounds in javascript and php. The code is pessimistic, and its so bad that it doesnt even get used, the author re-exports the function with :any types.
>FromSetupStore isnt necessary in the type names since its obvious where you are getting it from in the typehint
It's a type defined in an other file, and this isn't the only place where those are used.
>The underscore to represent some private type is a callback to some poor workarounds in javascript and php
It uses an underscore to indicate it should be exported to the library user. Again, you're not providing alternatives.
>The code is pessimistic, and its so bad that it doesnt even get used
It is used, the result is shown in
. The reason the implementation uses :any, is because that function has a lot of overloads.
>janny
Anon, that is THE guy that created vue.
>These people need golang.
Doesn't run in the browser.
Then they need VanillaJS
So, move verbose jsdoc doing the same thing, or no nice ide support for end users?
It means ditching the concepts of "setup stores" "actions getters" and "getter getters" and all this junk and actually just telling the computer what you want to do. Something the JScel cannot understand.
>document.querySelector('.nagger').innerHTML = ...
NOOOOOOOOO you can't do that, use my 50 nagger store objects, built with a function that returns a function tha needs 3 more objects with getter, setter and a bucnh of bullshit.
just use classes. all IDEs support code completion for those and you can generate a d.ts file without even using jsdoc annotations. javascript has types built in if you use classes, the shit in the OP only happens if you are attaching or inferring or mapping types from object literals.
>>how would you write it
>heres how I would write it
>>NOT LIKE THAT
ok
still easier to read than rust
>DefineSetupStoreOptions
>ExtractStateFromSetupStore
>ExtractGettersFromSetupStore
>ExtractActionsFromSetupStore
>storeSetup
>defineStore
Why??
Why not "setupStore" instead? Why they cannot keep with their own naming convention?
>5 votes
the setup store closed 2 years ago btw
>Retard tier: Can't read it
>Midwit tier: Can read it and think this is an accomplishment in itself
>Ascended tier: Can read it and identifies how extremely flawed it is
Costing who money?
I'm not even a js/ts dev and I can read that code.
>Is this not hard to be unreadable or not? Yes | No
Lol I fucking hate jeets so much.
But the Typescript is fine, it's obvious what it does if you've seen C++ templates and plain javascript.
Found the incompetent helloworldnagger
Readable it is. But not in the sense of understanding what it does.
I think it is retarded and ugly.
Aliasing a string is useless.
Then it is receiving a procedure as parameter, which might cause side effects.
And the options parameter is just atrocious. Too much abstraction for something that would be clearer in imperative style.
>Then it is receiving a procedure as parameter, which might cause side effects.
Are you having a laugh? That's called a dependency injection. That's an actual DI, not a service registry which is commonly wrongly called DI.
I know what DI is you fag. But it has its place.
Common sense and good taste dictate that this function would be better written in the conventional imperative manner.
There is such thing as too much abstraction.
This guy thinks the raw JS would be better than whatever this garbage is.
The problem is it's JS. TS is lipstick on a pig.
I use TS for my web apps because my only choices are plain JS or TS. I wish webdev wasn't so shitty but it is.
>TS is lipstick on a pig
Is that available as a sticker somewhere?
I pray every day for WASM to become a first class citizen on the web so we can get an actually good language to replace TS/JS.
Preferably something with a similar syntax to TS (minus the baggage), but types are real and available at runtime (like on C#) and with typed Enums and match (like Rust).
Unironically frontend rust would be god tier
Honestly I would rather have something with a GB instead.
*GC
But you would need to ship it to the client, thats pretty huge
Perhaps we could find a middle ground where the browser would have a GC the language can use, even if it's only for languages created for being used in WASM exclusively.
Nobody cares.
Then the wasm blob would have to somehow flag the browser gc what pieces of memory can be discarted as a lang agnostic gc cannot figure it out own its own, this would be a nightmare
It's readable but trash. People take it way too far. They see a feature and just assume they're supposed to use it or they're not doing it right.
A huge chunk of pajeet-tier devs take pride in making pseudo-obfuscated code on purpose, because they think it make them look clever.
this tbh senpai
remember genius admires simplicity while idiots admire complexity - Terry A Davis
a dunning kruger retard quotes this quote
Nope
this is ugly but only because the authors are unable to use typescript properly
>breaking backwards compatibility in order to improve the library
based
just stop updooting if you don't want that
Death to JavaScript
How is that less readable than C++ templates?
It's about the same. Both are terrible.
>developers who are used to reading/writing TS found TS to be readable
W-What?! Impossible!
who cares. even a pleb can understand it now, just enter the code into gpt4 and ask "what does it do"
filtered
>You are projecting your frustration with your own incompetence in TypeScript
Based vue dev.
>REEEEEEE you've been banned FOREVER that will show you
>*creates new account*
>AIEEEEEEEEEEEEEEEEEEE
>P.S. you have been banned
webfags really are insufferable
lol his tiny janny pecker got hard typing this
>you have been banned from interacting with any vuejs repositories
oh no
anyways
what a huge fucking faglord
It's a function that creates a store based on the id, storeSetup, and options. It returns a StoreDefinition. I'm sorry you're too stupid to read code.
I also hate typescript though.
At the point where you're asking for an options that contains three functions that "extract state from setup store", "extract getters from setup store", and "extract actions from setup store". You have left sane programming behind. These people need golang.
>you're costing people money
lmao what a piece of shit
>x?: any
this nagger misses the whole point of typescript
>TS
Typescript or transexuals?
It's the same thing