-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align Typescript & Runtype names #282
Comments
Yeahhh this is what I've been thinking for a long time, I'm glad to see you have provided some momentum. Generally speaking changing names of APIs could be a huge surprise to users and requires intermediate deprecation notices, but this time it would apparently be a quite reasonable change. There are some remaining tasks which should be done until v7, so we shall wait to seek for any resistive opinions in this issue. If no one comes, we'll introduce this change in v7. |
I would also like to add that we are forced to use String / Number / Boolean (notice first letter capitalized). TypeScript advices us to use only lower case versions (https://www.typescriptlang.org/docs/handbook/basic-types.html#about-number-string-boolean-symbol-and-object). This can be seen as very odd from perspective of new developers in projects. They are taught to NOT use capilatized versions. I don't know if there can be done anything. Best case would be to let us keep using those same types that TypeScript wants us and extract guard, check etc. methods to somewhere else. Other solution is to do a named import Just wanted to throw my .5cents. No expectations. |
I'm voting to keep current naming - it is accurate, comes from Data Structures theory and everyone (at least I have such experience) clearly understands the meaning - this is important additional benefit in communication with non-typescript devs: javascript and java devs, managers. |
That is just for TypeScript's intrinsic static types, but not for JS-level runtime objects. I understand the capitalized runtypes might be confusing about that, but I believe the difference between them is one of the first thing TS developers must learn. I think the best solution not to confuse them is to use named import, as you said.
Good catch. Though I think your table is a bit wrong at TypeScript naming; the first row must be "object". Although, maybe leaving |
I understand this request is somewhat controversial, so I'm expecting some resistance, and that is totally reasonable. I'm sure you have thought long and hard about your naming conventions, but as I foresee a major release coming up, I thought it's a good time to chuck this spanner in the works and see if there's anyone else that feels the same.
I'm slowly bringing in the runtypes package in to our development process, at my place of work, as I love it's API and the codebase is easy to work with. However, 1 thing that has initially caused some confusion in my team (especially those new to Typescript) is the naming of
Record
&Dictionary
.Because Typescript has already chosen to use a type
Record
in a similar way to what you've chosen to nameDictionary
, and you've chosen to useRecord
as a kind ofObject
validator, it seems there could be something more obvious and consistent.How would you feel about using
Object
instead ofRecord
&Record
instead ofDictionary
?This could well be considered more confusing, now that the community is used to the current naming, however, a part of me thinks it would be easier to get on board with if it was more aligned with Typescript.
Food for thought.
The text was updated successfully, but these errors were encountered: