Skip to content

Conversation

@KVSRoyal
Copy link
Contributor

@KVSRoyal KVSRoyal commented Jan 23, 2026

What

  1. Remove set and delete from core ReadOnlyDataController. They previously just logged an error and did nothing. Omitting set and delete is a cleaner API. This is outside the scope of the original issue but was discussed with @KetanReddy
  2. Introduce a ReadOnlyDataController on iOS. This wraps the core version of the same. A CompletedState on iOS will now include this controller.
  3. For parity, add a public makeReadOnly() to the iOS DataController. It's not used on iOS, however.

Why

#219

We should have parity across all platforms. This updates ios to match the same public API as the core for the Read-Only Data Controller. The read-only version of the data controller was introduced to allow users to access data / evaluate bindings after a flow has ended.

Change Type (required)

Indicate the type of change your pull request is:

  • patch
  • minor
  • major
  • N/A (this is part of the major release)

Does your PR have any documentation updates?

  • Updated docs
  • No Update needed
  • Unable to update docs

Comment on lines +62 to +65
public func makeReadOnly() -> ReadOnlyDataController? {
value.invokeMethod("makeReadOnly", withArguments: [])
.map { .createInstance(value: $0) }
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Question for reviewers: is this something that we actually want users to be able to access on core/ios/android/etc? It strikes me as a helper function that's been exposed to users.

Copy link
Contributor

Choose a reason for hiding this comment

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

I could see a case where a user might want to access it in a custom plugin but might be rare

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah. My preference is private/internal if possible. The more we expose, the larger our public api, and the higher the surface-area for breaking changes. There doesn't really appear to be a strong benefit to exposing this right now so I'm in favour of not to limit public api.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm, I revise my statement. It looks like it must be public in the web api because of the way we're using it. So I'll leave the iOS API so that there's parity.

@codecov
Copy link

codecov bot commented Jan 23, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (player-1-dot-zero@b2bd599). Learn more about missing BASE report.

Additional details and impacted files
@@                 Coverage Diff                  @@
##             player-1-dot-zero     #786   +/-   ##
====================================================
  Coverage                     ?   85.90%           
====================================================
  Files                        ?      507           
  Lines                        ?    22891           
  Branches                     ?     2656           
====================================================
  Hits                         ?    19664           
  Misses                       ?     2898           
  Partials                     ?      329           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

/** Wrapper for the Data Controller Class that prevents writes */
export class ReadOnlyDataController
implements DataModelWithParser<DataModelOptions>
implements Pick<DataModelWithParser<DataModelOptions>, "get" | "delete">
Copy link
Member

Choose a reason for hiding this comment

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

If the data controller is going to be read only we shouldn't support delete

@KVSRoyal KVSRoyal marked this pull request as ready for review January 26, 2026 18:39
@KVSRoyal KVSRoyal requested review from a team as code owners January 26, 2026 18:39
@KVSRoyal KVSRoyal merged commit 0a1abd4 into player-1-dot-zero Jan 27, 2026
14 checks passed
@KVSRoyal KVSRoyal deleted the ios-readonly-data-controller branch January 27, 2026 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants