player-ui / player Goto Github PK

Describe the bug

A binding like {foo.bar will have the { swallowed, causing it to be a false binding of two identifiers without the {

To Reproduce

Expected behavior

Error is thrown when two { aren't adjacent to each other.

The iOS ManagedPlayerViewModel tests cause random failures in CircleCI but not locally.

Explore different methods for asserting on published values to avoid tests failing in CI

Determine working model for releases

• Cadence
• Process
  • How to trigger a release
• Migration Guides
• Versioned documentation
• Prerelease testing plan

Generate API documentation for iOS using DocC

The core type for the collection reference asset defines a label as well as values. Currently the iOS CollectionAsset only renders values.

Update this asset to render the label to match the React reference asset

The release script should handle being called multiple times in case of failure for one of the steps.

• If a published version of a package already exists -- skip publishing and do nothing
• If a published version does not exist, attempt to publish and fail the script on failure

Open questions:

• If a package publishing fails, should we continue to try and publish others? or bail the whole script early? In either scenario, the overall script should fail.

The core input asset also declares a note field to display under the input.

Render the note field in the iOS reference input asset with the same styling as react

I would like to expand our documentation for getting started with Android.

Right now we have a read me that is as bare as it gets.
Including steps on how to run and test a local build of player on android would be great for anyone who wants to start and is new with android/kotlin.

Can add in any troubleshooting that you encountered during your setup.

Write out a .bazelrc.local during the circle build setup that defaults to using the --config=ci and the bazel cache write token

Allow us to enforce linting and formatting against build files as part of CI

Generate API documentation using Dokka

To better showcase various plugins and functionality, the iOS demo app needs to be enhanced to load more than flows for the reference assets.

The web storybook has some additional, non reference asset examples as well.

Update the iOS Demo app to give working examples of additional features:

• ManagedPlayer
• PubSubPlugin
• BeaconPlugin
• ExternalActionPlugin/ExternalActionViewModifierPlugin

These new examples should also include XCUI tests

Depends on #169

In the Android reference action asset

• Render a < icon next to the label based on metaData.role
• Do not render a button background when rendering the back icon

To better showcase various plugins and functionality, the Android demo app needs to be enhanced to load more than flows for the reference assets.

The web storybook has some additional, non reference asset examples as well.

Update the Android Demo app to give working examples of additional features:

• ManagedPlayer
• PubSubPlugin
• BeaconPlugin
• ExternalActionPlugin

These new examples should also include Espresso tests

To reduce the time it takes for new users to evaluate Player, we need to expand the reference asset set to incoporate more common user interaction patterns.

A choice asset represents a single selection choice, often displayed as radio buttons in a web context. This will allow users to test out more complex flows than just inputs + buttons.

Requirements

choice

• A choice asset must have a title to give the user context on what choice they are making
  • The title should be an asset
• A choice asset can have an optional note to provide more detailed information about the selection
  • The note should be an asset
• A choice asset should update the value of a binding property supplied to it
• A choice asset should retrieve validation information for its binding, and expose that for all rendering platforms to display
• A choice asset will have an array of choices
  • Each entry in choices will not be an asset, as the choice assets per platform will need direct control over the layout
  • Each entry must have a value that is set to the binding when the option is selected
    • The value should be a primitive
  • Each entry must have a label that describes what value is being selected
    • The label should be an asset

Execution

1. Create a new choice asset in the core reference assets and add types for the authored content, and the transformed content.
2. Create a transform for this choice asset
   1. The transform should use the binding and provide functions on the transformed type to make it simple for the rendering platform to select an option, similar to run in the action asset
   2. The transform should populate a property on each choice to indicate its selection status
   3. validation to be populated from the binding/schema information
      1. validation is not a content authored field
3. Add mocks to the mocks package to exercise required and optional fields, to ease unit testing, and implementations for rendering
4. Add the DSL Component for choice to allow programmatic content authoring
   1. DSL Docs
   2. Add unit test to verify JSON conversion of the DSL component
5. Add unit tests for the transform
   1. Verify selecting options
   2. Verify validation information being populated

In large projects, managing the transitive Player libraries (binding, expression, etc) can be frustrating when yarn or npm chooses to pull in a different version.

Moving to just exposing @player-ui/player and @player-ui/react as the public facing packages (and bundling the rest of core) should help reduce that churn.

Depends on #181

Consuming the new core choice, provide a rendering implementation in React that displays the asset as a radio buttons.

• Render the label of each choice entry next to the radio button

• Render the title of the choice above the radio buttons

• Render validation information below the radio buttons

Migrate away from CocoaPods as a package manager, and build through SPM

We will still publish to CocoaPods but we do not need to build and resolve our dependencies through it, as it complicates usage of Bazel

In order to benchmark each platform as well as core, we will need to add a performance test suite.

Specific cases for the following should be included at a minimum, with varying complexity:

• Templates
• Switches
• Applicability
• DataChangeListener

Give the consumers a way to render Android Player rendered UI as a @Composable so they are able to choose between rendering Composable Player assets and traditional Android view Player assets

We currently have working code for a composable Android ManagedPlayer (multi-flow experiences) as follows

@Composable
fun ManagedPlayer(
    plugins: List<Plugin>,
    flowManager: AsyncFlowIterator,
    onComplete: @Composable (CompletedState?) -> Unit,
    fallback: @Composable (Throwable) -> Unit,
    loading: @Composable () -> Unit = { CircularProgressIndicator() },
    modifier: Modifier = Modifier,
) {
    val viewModel = remember(plugins, flowManager) {
        object : PlayerViewModel(flowManager) {
            override val plugins = plugins
        }
    }
    LaunchedEffect(viewModel) {
        viewModel.start()
    }
    ManagedPlayer(viewModel, onComplete, fallback, loading, modifier)
}


@Composable
fun ManagedPlayer(
    playerViewModel: PlayerViewModel,
    onComplete: @Composable (CompletedState?) -> Unit,
    fallback: @Composable (ManagedPlayerErrorContext) -> Unit,
    loading: @Composable () -> Unit = { CircularProgressIndicator() },
    modifier: Modifier = Modifier,
) {
    Box(
        Modifier
            .fillMaxSize()
            .verticalScroll(rememberScrollState())
            .background(brush = outsideOrbVerticalGradient)
            .then(modifier),
        propagateMinConstraints = true,
    ) {
        val state by playerViewModel.state.collectAsState()
        when (val currentState = state) {
            ManagedPlayerState.NotStarted -> loading()
            ManagedPlayerState.Pending -> loading()
            is ManagedPlayerState.Running -> currentState.asset?.compose()
            is ManagedPlayerState.Error -> fallback(ManagedPlayerErrorContext(currentState.exception, playerViewModel::retry, playerViewModel::start))
            is ManagedPlayerState.Done -> onComplete(currentState.completedState)
        }
    }
}

class ManagedPlayerErrorContext(
    val error: Throwable,
    val retry: () -> Unit,
    val reset: () -> Unit
)

This code has not been moved into this project, we would like to potentially patternize it and move it over, as well as creating a similar composable for a single flow experience by feeding in an AsyncFlowIterator with one flow

The core input asset also declares a note field to display under the input.

Render the note field in the Android reference input asset with the same styling as react

Since auto skips doing any release with the documentation label, our release script that publishes docs doesn't run. We might need to break up the script, or call it some other way

Depends on #181

Consuming the new core choice, provide a rendering implementation in SwiftUI that displays the asset a list of "tiles". While the React implementation will use radio buttons, that UX is not as ideal on mobile devices, and we should opt for slightly larger controls.

A "tile" can be described as follows:

• A tile is a container with rounded corners, and a slight shadow to lift it off the content behind it
• A tile that is currently selected has no shadow, and a green stroke around the border of the tile

For this choice asset:

• Render the label of each choice entry inside each tile

• Render the title of the choice above the list of tiles

• Render validation information below the list of tiles

Is your feature request related to a problem? Please describe.
Would love to see different ways to enhance our documentation and guides. Player has a lot of moving parts and how things tie in together can be confusing at first glance. Some people may learn better through visuals.

Describe the solution you'd like
Update our documentation to have more visuals to show how things tie within player. Especially around the Content section. How we take your content to how it shows up on the page. And what that content looks like in code to the rendered view.

Additional context

Currently the Android assets only contain traditional Android view based assets.
Alongside the Composable player patternization, it would be good to have a ComposeReferenceAssetsPlugin containing the same reference assets but as composables using the following pattern

open class ComposableAsset<Data> constructor(assetContext: AssetContext, serializer: KSerializer<Data>, private val content: @Composable (AssetContext, Data) -> Unit) : DecodableAsset<Data>(assetContext, serializer) {
    override fun initView(): View = ComposeView(requireContext()).apply {
        setContent {
            content(assetContext, data)
        }
    }

    override fun View.hydrate() {
        require(this is ComposeView)

        setContent {
            content(assetContext, data)
        }
    }

    @Composable public fun compose() {
        content(assetContext, data)
    }
}

Assets should be rendered with the following compose function

@Composable
fun RenderableAsset.compose(modifier: Modifier = Modifier) {
    if (this is ComposableAsset<*>) Box(
        modifier,
        propagateMinConstraints = true,
    ) {
        compose()
    } else AndroidView(factory = ::FrameLayout, modifier) {
        assetContext.withContext(it.context).build().run { render() } into it
    }
}

There are some docs on how to get started w/ bazel and running tests/builds locally in the CONTRIBUTING.md, but nothing around system requirements, etc

We should also add common snippets (run all js tests, start docs locally, etc)

The reference react action asset currently renders a < icon when the value of the action indicates that the user would go backwards in the flow. Rather than have assets on each platform implement this check, we can move it into the transform and expose a generic property in the action metadata to make the coupling between icon and value looser.

• Move logic for determining isBackAction into the action transform and populate a role property in the metaData when applicable.

• Update the react asset to use metaData.role instead of checking the value directly.

Depends on #161

To better model some real world scenarios, the info asset should be able to render content below the actions.

Render the footer for the SwiftUI reference asset

Create an option within the existing Android demo app to render Compose Player UI, allowing user to switch between this option and Android view option

require #89 and #90

The release only publishes docs right now, we need to publish to each package manager (npm)

To better model some real world scenarios, the info asset should be able to render content below the actions.

Add a footer to the info asset and render it in the react reference asset

Intuit has a Medium blog for engineering related content, as a part of the 1.0 release, an article should be prepared for publishing to intro and give an overview of Player.

The published modules contain the basics of what we need to work, but we should add the rest of the metaData:

• Link to git repo
• Contributors (auto-generated from .all-contributorsrc/git log/etc)
• Issues Link
• Docs site
• License

• Add version switch to docs (latest, v0, next)
• Fix path stamping for non-next builds (this)

The core type for the collection reference asset defines a label as well as values. Currently the Android CollectionAsset only renders values.

Update this asset to render the label to match the React reference asset

Wrap https://github.com/Kotlin/binary-compatibility-validator in a Bazel test rule for API validation

Describe the bug

Asset Provider Plugin React code example is wrong

To Reproduce

1. Visit: https://player-ui.github.io/latest/plugins/asset-provider
2. See that the function is declared with an object, where as it should be declared with an array. Similar to this test case https://github.com/player-ui/player/blob/main/plugins/asset-provider/react/src/__tests__/index.test.tsx#L13 as reference

• OS: React
• Version 0.3.0 (latest)

Is your feature request related to a problem? Please describe.

When I write custom assets for my own project, there's no easy way to test them locally with sample Player content. What I end up doing often is copy-pasting almost the entire sample app module from the Player Android project, since the sample app is well put together. This is not a hard task, but it is tedious.

Describe the solution you'd like

It would be nice if the sample app can be extended in some way. Ideally, it should be flexible for

• small and simple projects where I can plug in the sample app, throw some Player content in the assets folder, and see how they render
• bigger projects where I can extend the sample app, customize it with additional asset functionalities to be demoed (like theme switching)
• complex projects where Player is only one of the capabilities/screens to be demoed in the app

Additional context

Depends on #164

Once segmented actions are available through the transform, we can add a tablet specific layout for the info reference asset that stacks the buttons horizontally, rather than vertically, with actions that would take the user back in the flow on the left and actions for advancing on the right.

Depends on #161

To better model some real world scenarios, the info asset should be able to render content below the actions.

Render the footer for the Android reference asset

https://player-ui.github.io/latest/assets/transforms

The cross platform link at the bottom of the page doesn't work, it should lead to this page (internal link)

https://player-ui.github.io/latest/guides/designing-semantic-assets

Reference Assets link at the top is incorrect, link to the current reference assets location

The release only publishes docs right now, we need to publish to each package manager (npm, maven central)

The reference react info asset segments actions based on their value, to display side by side in larger viewports.

To leverage this for tablet views in iOS and Android, we should move this segmentation logic to a transform. And remove the react specific code to leverage the transformed data.

Depends on #164

Once segmented actions are available through the transform, we can add an iPad specific layout for the info reference asset that stacks the buttons horizontally, rather than vertically, with actions that would take the user back in the flow on the leading edge of the screen, and actions for advancing at the trailing edge.

Depends on #169

In the iOS reference action asset

• Render a < icon next to the label based on metaData.role
• Do not render a button background when rendering the back icon, instead apply the background color to the text

Right now the remote caching is failing in circle for forked PRs due to a missing cache write token.

For forked PRs, we should allow cache reads, but disable writes

Is your feature request related to a problem? Please describe.
Our previous react player template was using create-react-app which isn't used anymore. It would be nice to have a new up to date template that people can pull and work with player to test things out.

This can be used with vite, nextjs, etc.
I believe the only requirements would be that it must be on React 17.

Describe the solution you'd like

Goal: If people want to test using player, they should be able to easily pull this repo and enter their desired content and have it render on the screen.
Templates for custom assets to see how things are being rendered may help as well.
You can also write documentation on a Using/Getting Started with React Player Guide

Additional context

The storybook integration today allows the user to manually view/edit the JSON content that powers the flow on screen.

It would be great for users to be able to see the TSX structure of the same view, allowing them to quickly get started in a DSL based local environment.

Publish API docs alongside the normal docs pages

Depends on #181

Consuming the new core choice, provide a rendering implementation in Android that displays the asset a list of "tiles". While the React implementation will use radio buttons, that UX is not as ideal on mobile devices, and we should opt for slightly larger controls.

A "tile" can be described as follows:

• A tile is a container with rounded corners, and a slight shadow to lift it off the content behind it
• A tile that is currently selected has no shadow, and a green stroke around the border of the tile

For this choice asset:

• Render the label of each choice entry inside each tile

• Render the title of the choice above the list of tiles

• Render validation information below the list of tiles