Queue Frontend Development - TISTATechnologies/caseflow GitHub Wiki

Definitions

• "task actions"

Relevant files

• task_action_repository.rb
  • referenced by func of actions in TASK_ACTIONS.json
  • defines a configuration used by QueueFlowModal.jsx
    • modal_title, modal_body
    • type: Task name
    • options: provided in dropdown menu in the modal
    • selected: initial selection in dropdown menu
    • modal_selector_placeholder: placeholder text for dropdown menu
    • redirect_after: redirect path after submit is pressed and there's no error
    • value: used by QueueApp.jsx to route a URL to a modal component
    • custom configurations: back_to_hearing_schedule
• QueueFlowModal.jsx
  • modal window that pops up when a user selects a task action from the dropdown (in the Case Details page of an appeal)
  • Many modals simply feed props to QueueFlowModal in order to configure submit, success, pathAfterSubmit, validateForm, button, reloadPageAfterSubmit etc.
  • Some props also come from the Redux state, e.g., the success and error messages.
• QueueLoadingScreen.jsx
  • used to (potentially) load queues: queueConfig, fetchAllAttorneys, fetchAmaTasksOfUser, loadAttorneys
  • sets common Redux state.ui properties, e.g. userId, userRole
• app/controllers/tasks_controller.rb
  • Update TASK_CLASSES_LOOKUP if a new task type is to be created via the TaskController. These task types are sent to the frontend via TaskActionRepository's type or options parameters.
  • The controller calls task.update_from_params so the new task model should implement update_from_params or update_with_instructions.

Available actions

• An appeal's case detail pages shows available actions for the logged-in user.
• A task defines available_actions which references constants in TASK_ACTIONS.json.
• TaskActionHelper build a hash of available actions by returning the TASK_ACTIONS constants or calling func.
• A task calls TaskActionHelper.build_hash to create the list of available actions.
• The logic to determine available actions is sometimes defined in task_action_repository.rb and other times in the task itself.

Redux state

Ever see this in React components: export default (connect(mapStateToProps, mapDispatchToProps)(QueueLoadingScreen)). Here's what it's used for:

• mapStateToProps maps Redux state to the component's props
  • it calls functions like getTasks and taskById (defined in selectors.js)
• mapDispatchToProps maps results of functions (defined in uiActions.js) to props and Redux state
  • functions like setUserId and fetchAllAttorneys
  • The functions can be called within the file to update the state and hence the page.
  • These functions return an object with type being the Redux action (defined in uiConstants.js) and payload being the thing to be added to props.

Reducers are defined in uiReducer.js and are keyed off Redux action type and do the actual update to the Redux state.

• When are these reducers called?

Selectors are defined in selectors.js and are what we use to read and filter through the Redux state. Here's a quick article with more on what selectors are and why we use them.

React Component Trees for reference

(Rough) React component tree for Case Details page

• Queue
  • ReduxBase
    • QueueApp.jsx
      • CaseDetailsLoadingScreen.jsx
        • SomeCustomModal.jsx (e.g., AssignToView.jsx)
          • QueueFlowModal.jsx

(Rough) React component tree for Judge Case Assignment page

• Queue
  • ReduxBase
    • QueueApp.jsx
      • QueueLoadingScreen.jsx
        • JudgeAssignTaskListView.jsx

Routes

Let's track how :user_id is propagated to components:

Route /queue/:user_id(*rest)(.:format) is handled by

• app/controllers/legacy_tasks_controller.rb
  • which is an ApplicationController (which sets current_user based on the authenticated logged-in user)

If the request is for html, then controller will render "queue/index", which is provided by

• app/views/queue/index.html.erb which
  • sets props.userId based on the current_user;
  • forwards the props to children React components, including QueueApp.jsx;
  • and loads React component generator called Queue, which:
    • is defined in client/app/queue/index.jsx
    • and wraps client/app/queue/QueueApp.jsx in a ReduxBase that sets up the Redux store with initialState

QueueApp.jsx feeds the props (including userId) to other React components.

QueueLoadingScreen.jsx sets ui.loadedUserId in the Redux store based on props.userId.

How are alerts displayed in Queue pages?

(Or how to trigger the display of an alert there?)

Success messages are typically shown with the showSuccessMessage ui action. Same for errors. Most components will check the redux store to show any error messages that are present. A lot of components will use the requestSave ui action which handles sending a request to the backend and dispatching the success message if it was provided, or an error if the request fails.

Error and success messages are stored in state.ui.messages.error  and state.ui.messages.success respectively.

You may also want to subsequently clear the alert from the redux state by using something like resetSuccessMessages

Useful Links

Below are pages within the greater Caseflow wiki related to Frontend development

• Frontend Application State
• Frontend Basic Principles
• Frontend Best Practices
• Frontend Directory Structure
• Frontend Things to Avoid