Skip to content

Editorial review: Document FileSystemObserver #38270

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

Merged
merged 17 commits into from
Feb 27, 2025

Conversation

chrisdavidmills
Copy link
Contributor

@chrisdavidmills chrisdavidmills commented Feb 21, 2025

Description

Chrome 133 supports the FileSystemObserver interface, which allows you to observe changes to the underlying file system via a standard observer mechanism.

This PR adds documentation for the new functionality, which mainly consists of new reference pages for the new interface.

Note that the feature is currently non-standard (see whatwg/fs#165), although it should be added to the spec soon. I have currently documented it as such.

Motivation

Additional details

See the relevant ChromeStatus entry for data: https://chromestatus.com/feature/4622243656630272

Relevant blog post: https://developer.chrome.com/blog/file-system-observer#start_observing_a_file_or_directory

Related issues and pull requests

Related BCD: mdn/browser-compat-data#25986

@chrisdavidmills chrisdavidmills requested review from a team as code owners February 21, 2025 14:48
@chrisdavidmills chrisdavidmills requested review from sideshowbarker and pepelsbey and removed request for a team February 21, 2025 14:48
@github-actions github-actions bot added Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed labels Feb 21, 2025
Copy link
Contributor

github-actions bot commented Feb 21, 2025

Preview URLs (6 pages)
Flaws (6)

Note! 5 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Web/API/File_System_API
Title: File System API
Flaw count: 6

  • broken_links:
    • /en-US/docs/Web/API/window/showOpenFilePicker is ill cased
    • /en-US/docs/Web/API/window/showDirectoryPicker is ill cased
    • /en-US/docs/Web/API/window/postMessage is ill cased
  • macros:
    • Macro produces link /en-US/docs/Web/API/window/showOpenFilePicker which is a redirect
    • Macro produces link /en-US/docs/Web/API/window/showDirectoryPicker which is a redirect
    • Macro produces link /en-US/docs/Web/API/window/postMessage which is a redirect
External URLs (14)

URL: /en-US/docs/Web/API/FileSystemChangeRecord
Title: FileSystemChangeRecord


URL: /en-US/docs/Web/API/FileSystemObserver
Title: FileSystemObserver


URL: /en-US/docs/Web/API/FileSystemObserver/disconnect
Title: FileSystemObserver: disconnect() method


URL: /en-US/docs/Web/API/FileSystemObserver/observe
Title: FileSystemObserver: observe() method


URL: /en-US/docs/Web/API/FileSystemObserver/FileSystemObserver
Title: FileSystemObserver: FileSystemObserver() constructor

(comment last updated: 2025-02-27 19:01:14)

@chrisdavidmills chrisdavidmills changed the title Document FileSystemObserver Technical review: Document FileSystemObserver Feb 21, 2025
Copy link
Contributor

@tomayac tomayac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great. Left a bunch of suggestions.

@chrisdavidmills
Copy link
Contributor Author

@tomayac thanks for the review! I think I've answered everything. Let me know if you feel this needs anything else, or give me an LGTM if you are happy with it.

@chrisdavidmills chrisdavidmills changed the title Technical review: Document FileSystemObserver Editorial review: Document FileSystemObserver Feb 24, 2025
@wbamberg wbamberg requested review from wbamberg and removed request for tomayac February 24, 2025 16:39
Comment on lines 30 to 32
#### `FileSystemChangeRecord` structure

`FileSystemChangeRecord` objects have the following structure:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are really two ways of dealing with dictionaries:

  1. document them inline as anonymous objects (so under the records bullet above say something like "an array of objects contain details of all the observed changes. Each object has the following properties:"
  2. document them in separate pages, like we do for example with https://developer.mozilla.org/en-US/docs/Web/API/RequestInit.

Because this is quite a complex object it might be worth going with (2) here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I've given it a go. My next commit now contains a new FileSystemChangeRecord page, which is included in the sidebar and linked to from the appropriate places.

@tomayac
Copy link
Contributor

tomayac commented Feb 27, 2025

Just confirming that https://glitch.com/edit/#!/file-system-observer?path=.prettierrc%3A1%3A0 is by me, @tomayac. It's the demo embedded in the article on chrome.dev.

Screenshot 2025-02-27 at 11 06 13

@Elchi3
Copy link
Member

Elchi3 commented Feb 27, 2025

What's the license of your code, @tomayac? If we want to publish your code (at a later stage) in https://github.com/mdn/dom-examples (CCO) would that be compatible?

@tomayac
Copy link
Contributor

tomayac commented Feb 27, 2025

What's the license of your code, @tomayac? If we want to publish your code (at a later stage) in https://github.com/mdn/dom-examples (CCO) would that be compatible?

All our code samples are Apache-2.0 licensed. You can publish the sample without any worries.

@chrisdavidmills
Copy link
Contributor Author

What's the license of your code, @tomayac? If we want to publish your code (at a later stage) in https://github.com/mdn/dom-examples (CCO) would that be compatible?

All our code samples are Apache-2.0 licensed. You can publish the sample without any worries.

Thanks @tomayac; see #38270 (comment).

Copy link
Collaborator

@wbamberg wbamberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of suggestions in the new FileSystemChangeRecord page.

Copy link
Collaborator

@wbamberg wbamberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 thank you Chris!

@wbamberg wbamberg merged commit 328a784 into mdn:main Feb 27, 2025
9 checks passed

{{APIRef("File System API")}}

The **`FileSystemChangeRecord`** dictionary of the {{domxref("File System API", "File System API", "", "nocode")}} contains details of a single change observed by a {{domxref("FileSystemObserver")}}.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wbamberg @chrisdavidmills Any reason for documenting this dictionary in its own page rather than inlining it, as per our typical policy?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's discussed here: #38270 (comment). Arguably, because it's a large and complex object, it's easier to read the docs when it is a separate page than when it is inline.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel very strongly though. I don't think this is a clear "use a dictionary" case - in particular, it is only used in that one place. But I could see the constructor page getting pretty unwieldy with all those indented lists to keep straight.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK that sounds reasonable. Just making sure we are not making more undesirable stuff that we have to clean up laer.

cssinate pushed a commit to cssinate/content that referenced this pull request Apr 11, 2025
* Document FileSystemObserver

* Update files/en-us/web/api/filesystemobserver/filesystemobserver/index.md

Co-authored-by: Thomas Steiner <[email protected]>

* Update files/en-us/web/api/filesystemobserver/index.md

Co-authored-by: Thomas Steiner <[email protected]>

* Update files/en-us/web/api/file_system_api/index.md

Co-authored-by: Thomas Steiner <[email protected]>

* Fixes for tomayac review comments

* Update files/en-us/web/api/file_system_api/index.md

Co-authored-by: wbamberg <[email protected]>

* Update files/en-us/web/api/filesystemobserver/disconnect/index.md

Co-authored-by: wbamberg <[email protected]>

* Update files/en-us/web/api/filesystemobserver/filesystemobserver/index.md

Co-authored-by: wbamberg <[email protected]>

* Update files/en-us/web/api/filesystemobserver/filesystemobserver/index.md

Co-authored-by: wbamberg <[email protected]>

* Update files/en-us/web/api/filesystemobserver/index.md

Co-authored-by: wbamberg <[email protected]>

* Update files/en-us/web/api/filesystemobserver/observe/index.md

Co-authored-by: wbamberg <[email protected]>

* Update files/en-us/web/api/filesystemobserver/observe/index.md

Co-authored-by: wbamberg <[email protected]>

* Add FileSystemChangeRecord page, other fixes from wbamberg review

* Update files/en-us/web/api/filesystemchangerecord/index.md

Co-authored-by: wbamberg <[email protected]>

* Update files/en-us/web/api/filesystemchangerecord/index.md

Co-authored-by: wbamberg <[email protected]>

* Update FileSystemChangeRecord description

---------

Co-authored-by: Thomas Steiner <[email protected]>
Co-authored-by: wbamberg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants