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
[JavaScript] Private fields and private methods are now enabled #5386
Comments
@Rumyra Please correct me if I am going in the wrong direction. |
Hi @Blakelist7 :) I'm yet to review what's required - I'll update this issue for you once I have 👍 |
Seems as though a lot of this list is being dealt with in this PR #5690 - I'll review here again once that's been merged We should concentrate on the class reference pages - there's a lot of pages that need updating with private field/methods on MDN. Here's a list Pages that need a review & updated informationFields:
Methods:
New pages neededLeaving here for ref https://tc39.es/proposal-class-fields/unified.html & https://github.com/tc39/proposal-class-fields#class-field-declarations-for-javascript |
So in #5690, it came up that maybe instead of having one page that covers both fields and methods, there should be separate pages. This issue seems to assume that structure. Is there an editorial reason for that? I’m asking not to push back, as I nearly split the page myself and so am quite open to the idea. I more want clarity/a working out of best practices here before I clean up #5690 and submit it for final merge. |
@meyerweb No idea about editorial process. But IMO it is only a good idea to have separate pages when it is clearly a bad idea to have a single page. i.e. you separate pages when things are clearly separate ideas/concepts that share no information or common thinking, or because you have something so monolithic you can't see the wood for the trees, or for discoverability via search etc. To my mind these concepts go together and I personally would not split them. Or at least I would look at the finished doc and think "could someone find this by search", "is this too intimidating for the reader" etc. I'm pretty sure you can do what you like and then we can split this later if it becomes unmanagable. |
@Rumyra I assigned this to me on an old non-updated tab, so did not see all this chit chat. I'm putting my hand up to own this but happy for you to punt it over to someone else. As no one has done it, I have created this for BCD: mdn/browser-compat-data#10854 If this belongs to me then I'd wait on #5690. After that goes in this is pretty easy because mostly it is just removing mentions of the preference (e.g. Experimental features) etc. My interest is because I started thinking about #5380 , which provides an easy way to check whether a private instance variable exists. That would update both docs. I'm actually wondering if you'd like to do the work on that @meyerweb because you're clearly much better at Javascript docs than I am :-) ? |
@meyerweb Pretty much what @hamishwillee said
I err on the side they should be separate pages, but also this shouldn't be a blocker to getting the amazing work you've done merged - also what Hamish said
Yes we can absolutely do this, unless of course you want to and it's not difficult @hamishwillee Thank you 🙏 yes there is the little bits for a release project that would still need to be done (BCD, notes etc...) so I am extremely happy for you to take this on... it's outside the scope of Eric's PR and here I was merely reviewing what needed to be done content wise as it was quite a few pages 👍 |
@Rumyra IMO everything needed for release is done (there is always more that "might perhaps be done", but nothing blocking) Status of release docs tracking:
|
Thanks @hamishwillee - looks super 🙌 |
Acceptance criteria
Features to document
One issue for both as I'm sure this affects similar pages - probably best to tackle together
Related Gecko bugs
For folks helping with Firefox-related documentation features — make sure above AC have been done, but also:
The text was updated successfully, but these errors were encountered: