Forge @next Roadmap/Proposals

[DRiFTy17]

See the following proposals to get an idea of what we are planning for when it comes to version next major version of Forge!

The focus of this version will be around improving the DX and usage patterns across the library, as well as how the components are architected and composed together.

We will also focus on performance in this iteration to ensure that we reduce forced reflows and any potential blocking processes where possible.

Proposals

1. Statically implementing dynamic components (complete)
2. Refactor components that use light DOM (complete)
3. Style abstraction library (complete)
4. Move all native elements to shadow DOM (complete/on hold)
5. Remove MDC JavaScript dependency (complete)
6. refactor/remove the ripple interaction/component (complete)
7. Adjust floating label interaction (complete)
8. Accessibility audit and proxy API (complete)
9. Form compatibility (complete)
10. Utilize constructable stylesheets (complete)
11. Introduce design tokens (complete)
12. Redesign chip component (complete)
13. Introduce plugin/hook system (in review)
14. Introduce global configuration system (complete)
15. Redesign internal architecture to better support functional extension (in review)
16. Re-evaluate testing tools (complete)
17. Implement virtualization (in progress)
18. Stacking toast notifications (in review)
19. enable input-label association without explicit ids (complete)
20. disconnect addon-end slot disabled state in form fields (complete)
21. implement ElementInternals APIs (complete)
22. create a split-button component (complete)
23. standardize expectations for "change" event and state synchronization (complete)

[samrichardsontylertech]

I think we should give some attention to responsive design in the next release. Most Forge components adapt well to different container sizes, but some of the larger ones like the paginator and toolbar can be difficult to work with when space is constrained. Container queries might help here once they're widely available. Before that we can still find ways to make designing and coding responsively easier.

We should also consider the dialog component in this. The way it's implemented right now discourages responsive design, almost requiring it to be opened in full or partial screen mode and remain that way for its lifetime. I've seen a lot of questionable usage stemming from this. With smarter CSS we could default to an auto-switching full screen mode without hurting customization. Other modal components might be worth taking a look at also.

[DRiFTy17]

Great ideas! I can definitely see us improving various components through these patterns.

Another thing we may want to add to this topic is adapting our dropdown-style components (select, menu, autocomplete, date-picker... etc.) to better support mobile contexts. In the past we had automatically converted these to render in a dialog but that was fairly short sighted, and has since been removed for Forge 2.0. We will want to revisit this at some point, whether that be guidance, configuration, or automated handling.

[samrichardsontylertech]

Definitely. Let's look into what mobile platforms are doing and see if we can come up with patterns that feel more native.

[DRiFTy17]

Another route we could go with the mobile aspect is to more seamlessly support the native platform controls for things like <select> and <input type="date">. This could be in the form of guidance and/or something built-in to the component to help facilitate switching between them based on platform. Just a though, but something worth exploring.