NGRX FIFO قائمة انتظار العمل دون اتصال مع RxJS

TL ؛ DR بحاجة إلى نصائح لجهاز NGRX إجراء إعادة محاولة طابور FIFO باستخدام RxJS وتراجع إعادة المحاولة/التراجع الأسي (مع الحد الأقصى للتراجع من 30 دقيقة).

هنا أحاول وصف المنطق المحتمل لمنطق إعادة المحاولة المستندة إلى الصادر. هذا المثال غير مكتمل وليس لدي حاليًا أي فكرة حقيقية/نظيفة حول كيفية التعامل مع الحالات التالية:

  • action outbox -- failed item retries as a retry queue handling as a FIFO
  • multiple offline updates to same entity with first update failing properly 400
  • entity backup -- maybe sneak peak to https://github.com/johnpapa/angular-ngrx-data tracking or maybe just deep clone & insert if not already there.

بعض الإجراءات التي ربما تكون الأكثر حاجة لاستخدامات عامة دون اتصال هي:

  • وCREATE </لى>
  • وUPDATE </لى>
  • وحذف </لى>

تعريف المنطق الصادر

  • إذا كان صندوق البريد! = فارغًا ونحن "عبر الإنترنت" ، فجرِّم الإجراء الصادر في صندوق الصادر FIFO مع فترة إعادة المحاولة المتعفنة (تصل إلى نقطة مثل الفاصل الزمني 30 دقيقة كحد أقصى أو ما إلى ذلك)
  • معالجة إجراء واحد فقط من صندوق الصادر في كل مرة
  • عند الخروج من صندوق الصادر ، يتم فقد كل شيء في صندوق البريد.

Offline execution of Actions & Reducers & Effects

وصف الدولة:

export interface TodoState extends EntityState {
   backupEntities: { 
      [id: string|number]: TodoModel
   }
}

// Outbox should be it's own feature state since it's a FIFO queue
export interface OutboxState {
   fifoHandleIds: string[],//fifo order is kept here ( object properties not stable as we all know )
   outbox: {
      [outboxHandle: string]: ADD_TODO|UPDATE_TODO|DELETE_TODO //...
   },
   currentRetryCount: number,//retry count for first item in outbox
   processingHandleId: string,//outbox item currently in execution
}

// Outbox should be it's own feature state since it's a FIFO queue
export interface OnlineState {
   online: boolean;
}

إنشاء </قوي>

  • ADD_TODO:
    • payload:
      • action generator/class adds an operation handle if not given
      • action generator/class generates id as UUID if not given
    • reducer:
    • handles the optimistic creation
    • effect:
      • calls REST service without added UUID
  • ADD_TODO_SUCCESS:
    • payload:
      • generated UUID from ADD_TODO payload
      • operation handle from ADD_TODO payload
      • server response as the payload
    • reducer:
      • updates entity in store to new UUID with payload
      • checks if operation handle is in outbox
      • if it is
        • remove related entry ( this was a retry )
        • if processingHandleId matches -> set to '' & set currentRetryCount to 0
  • ADD_TODO_ERROR:
    • payload:
      • original ADD_TODO action
      • server response
    • reducer:
      • if server response 500 || timeout
      • checks if operation handle is in outbox
        • if it isn't
        • adds the whole action into outbox state
        • if it is
        • if processingHandleId matches -> set to ''
        • increase currentRetryCount
      • if server response 400 remove original added UUID entity
      • checks if operation handle is in outbox
        • if it is
        • if processingHandleId matches -> set to '' && set currentRetryCount to 0
        • remove related entry ( this was final retry containing errors )

<�القوي> UPDATE </قوي>

  • UPDATE_TODO:
    • payload:
      • action generator/class adds an operation handle if not given
    • reducer:
      • takes backup of the original entity
      • handles the optimistic update
    • effect:
      • calls the REST service
  • UPDATE_TODO_SUCCESS:
    • payload:
      • operation handle
      • server response as the payload
    • reducer:
      • checks if operation handle is in outbox
      • if it is
        • remove related entry ( this was a retry )
        • if processingHandleId matches -> set to '' & set currentRetryCount to 0
  • UPDATE_TODO_ERROR:
    • payload:
      • original UPDATE_TODO action
      • server response
    • reducer:
      • if server response 500 || timeout
        • checks if operation handle is in outbox
          • if it isn't
            • adds the whole action into outbox state
          • if it is
            • if processingHandleId matches -> set to '' & increase currentRetryCount
      • if server response 400
        • remove updates made by replacing using backup
        • remove backup
        • checks if operation handle is in the outbox
        • if it is
          • if processingHandleId matches -> set to '' && set currentRetryCount to 0
          • remove related entry ( this was final retry containing errors )

على حذف

  • DELETE_TODO:
    • payload:
      • action generator/class adds an operation handle if not given
    • reducer:
      • takes backup of the original entity
      • handles the optimistic store delete
    • effect:
      • calls the REST service
  • DELETE_TODO_SUCCESS:
    • payload:
      • operation handle
      • server response as the payload
    • reducer:
      • checks if operation handle is in outbox
      • if it is
        • remove related entry ( this was a retry )
        • if processingHandleId matches -> set to '' & set currentRetryCount to 0
  • DELETE_TODO_ERROR:
    • payload:
      • original DELETE_TODO action
      • server response
    • reducer:
      • if server response 500 || timeout
        • checks if operation handle is in outbox
          • if it isn't
            • adds the whole action into outbox state
          • if it is
            • if processingHandleId matches -> set to '' & increase currentRetryCount
      • if server response 400
        • restore deleted entity using backup
        • remove backup
        • checks if operation handle is in the outbox
          • if it is
            • if processingHandleId matches -> set to '' && set currentRetryCount to 0
            • remove related entry ( this was final retry containing errors )
0