Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-45885

Decide and document output components



    • Improvement
    • Status: Closed
    • Minor
    • Resolution: Deferred
    • 2.8
    • None
    • Libraries
    • 40
    • FRONTEND Sprint 13


      This is an essential part of the task - unfortunately the approaches are broad and what we choose now we have to commit to and live with.
      It has to meet our needs now and in the future.

      Some of the things that need to factor into this decisions are:

      Element and component re-use
      Re-use is key to this approach. We want to have components containing existing elements and components, and when we want to change how an element looks we want that change reflected in all uses of the element within other components that don't require it to look different.
      This way you can style a button and instantly have the look updated across other components like search forms containing buttons.

      Elements and components can be complex
      Elements don't need to be easy to write - they should be feature full and limited in number. Developers should not write components instead they should be re-using the available elements and components.

      Overriding a render to change how an element must be both easy and robust
      Re-use is key as per the above point.
      However we need to achieve this in such a way that we don't introduce magic and keep things simple to understand and override.
      We have to be able to deal with state and attribute requirements of the element in relation to its parent component and do it in such as way that the state is owned by the component and attributes are owner by the render method. and keep it all understandable.




            samhemelryk Sam Hemelryk
            samhemelryk Sam Hemelryk
            David Woloszyn, Huong Nguyen, Jake Dallimore, Meirza, Michael Hawkins, Raquel Ortega, Safat Shahin, Stevani Andolo
            0 Vote for this issue
            1 Start watching this issue