Skip to content
This repository has been archived by the owner on Nov 27, 2020. It is now read-only.

7.0 features (for discussion) #143

Open
timarney opened this issue Dec 3, 2019 · 2 comments
Open

7.0 features (for discussion) #143

timarney opened this issue Dec 3, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@timarney
Copy link
Member

timarney commented Dec 3, 2019

Initial list:

We want to get the most we can from a major breaking change so looking to bulk release a new set of features and updates.

The list

  • Repeater fields (The repeater! #132)

  • Plugins some discovery work here @smcmurtry (https://github.com/cds-snc/feedback-plugin)

  • Global JS files
    Add the ability to use "global js files" i.e. I need this code avail for all my routes (

    <script src="/dist/{{""|jsFile("global") }} "></script>
    )

  • Macro cleanup (some work here Cleanup macros #134) + extending radios + checkboxes (see The repeater! #132 (comment)) adding the ability to pass attributes to individual components

  • Toggle component (add the ability to show hide fields / area) based on a form selection - i.e. revealing additional fields based on selection.

  • Documentation

    • More docs around the Routes and Middleware i.e. a user wants to use a plain route without the en/fr prefix
  • Migration guide .... how to migrate from 6.x to 7.0

  • Ensure things move toward people can understand the setup enough (given) some digging that they can feel comfortable contributing. We can't rely on person X or person Y being available to do core implementations so we need to keep core Express JS type setup top of mind.

  • *Accessibility fixes

  • @JuliannaR is working on submitting

TBD

@timarney timarney added the enhancement New feature or request label Dec 3, 2019
@dsamojlenko
Copy link
Member

A couple suggestions:

  • Support for getting named routes with params (something like this)
  • Support more CRUD-y controllers
  • Improved Flash Messaging helpers
  • Convert all styles to tailwind?

@smcmurtry
Copy link
Collaborator

@dsamojlenko I am highly in favour of converting all styles to tailwind but I think it will be pretty time consuming:

  • the amount of existing css means the conversion will need to occur in multiple PRs
  • there will be collisions between the custom css and tailwind that will need to be figured out if we want to keep the app looking right between the PRs [1]

[1] I just ran into a collision trying to set the font colour of an anchor to white. Adding a "text-white" tailwind class was getting overwritten by our custom css.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants