Skip to content
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

New documentation site #112

Open
millsp opened this issue May 18, 2020 · 8 comments
Open

New documentation site #112

millsp opened this issue May 18, 2020 · 8 comments
Assignees
Labels
docs Related to the docs enhancement Improving something feature Add new features help needed Extra attention is needed
Projects

Comments

@millsp
Copy link
Owner

millsp commented May 18, 2020

🍩 Feature Request

Is your feature request related to a problem?

The current docs website is OK but we could do better.

Describe the solution you'd like

We need to build a better documentation website with docz. This is a feature that does not exist within docz so we will have to:

  • parse the code
  • extract docs
  • generate markdown pages
  • link doc [[references]]
  • link sources on repos

Describe alternatives you've considered

Teachability, Documentation, Adoption, Migration Strategy

@millsp millsp added docs Related to the docs enhancement Improving something feature Add new features labels May 18, 2020
@millsp millsp self-assigned this May 18, 2020
@mesqueeb
Copy link
Contributor

mesqueeb commented Jul 5, 2020

Just to give me 2 cents:
There are many types I'm not 100% sure of how & why to use. Some types are also similar to native TS types, so I often wonder the benefit of the TS-Toolbelt one over the native one.

If you want I can go through the entire list of types and write up one by one why I don't understand a type/example.
Let me know if this would help.

@millsp
Copy link
Owner Author

millsp commented Jul 5, 2020

Yes, thanks, that would be amazing! This is great help :)

The idea behind ts-toolbelt having all of the types is that:

  • Some of them fix non-obvious bugs (like the original Pick/Omit not working with unions)
  • We provide a single API for the type system, replacing ts type utilities, that can evolve in the future as needed. Another example is Record, that used to be the same as ts' but now has options to make fields ? or readonly.

Looking forward to your comments on the docs! Thanks

@mesqueeb
Copy link
Contributor

mesqueeb commented Jul 14, 2020

@millsp

I spent about 2 hours this morning reviewing the current types.

I have difficulties understanding why you provide wrappers like these:
How/why should we use them?

  • Any/x
  • Class/Class
  • List/List
  • Object/Object
  • String/String
  • Union/Union

& I have difficulties understanding almost everything under:

  • Misc/…

Then I realised I only have real experience with your O / Object types, so I just focused my review on those types, and I went through the entire list and made notes:

Not 100% sure what it does exactly + it has no example:

  • O.AtLeast
  • O.Either
  • O.Has / O.HasPath / O.Includes (I think this can be used for conditional TS types, but a specific example / use case would be really good here)
  • O.ListOf
  • O.Modify
  • O.Union (what’s the use case?)
  • O.Unionize

Not 100% sure what it does exactly even though it has an example:

  • O.Invert (the example doesn’t really show what the resulting type is, making it difficult to reason about)

The difference is not super clear between:

  • O.Diff ⇔ O.Intersect
  • O.Keys ⇔ (native) keyof T
  • O.Exclude ⇔ O.Filter ⇔ O.Omit ⇔ (native) Omit (also want to mention the native "Exclude" is easier to understand over O.Exclude because it’s not focussed on Objects)
  • O.Pick ⇔ O.Select ⇔ (native) Pick
  • O.Readonly ⇔ (native) Readonly
  • O.Record ⇔ (native) Record
  • O.Required ⇔ (native) Required (I do understand the advantage of O.Compulsory, but not of O.Required over the native option)

"Keys" variants:

  • All of the "Keys" variants are quite difficult to understand imo (and maybe we should not show them in the docs, or make them searchable but don’t show them in the index on the left?)

"Up" variants:

  • So I’m wondering if the "Up" variants can’t be the default behaviour and we get rid of the base types. It will reduce cognitive strain when people want to get familiar with your library.

"Path" variants:

  • It’s not super clear if the type will return just what’s retrieved at the "path", OR it will make the changes at the "path" but return the entire object type again.

Overall:

  • I think it’d be much clearer if each type has an example and the example actually shows how the new type will look when the ts-toolkit type is applied.

I hope this helps <3

@millsp
Copy link
Owner Author

millsp commented Jul 14, 2020

Amazing, thank you so much for your feedback. Thanks for taking the time!

@millsp millsp added the help needed Extra attention is needed label Jul 15, 2020
@millsp millsp added this to To do in Board via automation Jul 15, 2020
@stale
Copy link

stale bot commented Sep 13, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Sep 13, 2020
@millsp millsp removed the wontfix This will not be worked on label Sep 14, 2020
@stale
Copy link

stale bot commented Nov 14, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Nov 14, 2020
@millsp millsp removed the wontfix This will not be worked on label Nov 14, 2020
@stale stale bot added the wontfix This will not be worked on label Jan 14, 2021
Repository owner deleted a comment from stale bot Jan 14, 2021
@stale stale bot removed the wontfix This will not be worked on label Jan 14, 2021
@stale stale bot added the wontfix This will not be worked on label Mar 19, 2021
@stale stale bot closed this as completed May 10, 2021
Board automation moved this from To do to Done May 10, 2021
@millsp millsp reopened this May 26, 2021
Board automation moved this from Done to In progress May 26, 2021
@stale stale bot removed the wontfix This will not be worked on label May 26, 2021
@waynevanson
Copy link

I like having documentation inline with the code. It's helpful and I don't really need to visit the docs too often unless I want to read everything and engage in some research.

in fp-ts, a package called doc-ts has been made to get the tsdoc comments and create a site with it: https://gcanti.github.io/fp-ts/.
Every new feature has the comments, so every release has up to date docs.

Would you interested in something similar? Surely we could generate an output for use with docz

@stale stale bot added the wontfix This will not be worked on label Aug 18, 2021
Repository owner deleted a comment from stale bot Aug 18, 2021
@stale stale bot removed the wontfix This will not be worked on label Aug 18, 2021
Repository owner deleted a comment from stale bot Aug 18, 2021
@stale stale bot added the wontfix This will not be worked on label Oct 20, 2021
@mesqueeb
Copy link
Contributor

Fighting with the stale bot XD

@stale stale bot removed the wontfix This will not be worked on label Oct 20, 2021
Repository owner deleted a comment from stale bot Oct 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Related to the docs enhancement Improving something feature Add new features help needed Extra attention is needed
Projects
Board
  
In progress
Development

No branches or pull requests

3 participants