Натоварени седмици зад нас в фронтенд отдела на екипа на sensenet. Новите функции на бекенда и нашият текущ DMS MVP генерираха много задачи и ни дадоха много точки за подобрение. Но сега пуснахме всички тези нови неща, така че можем да се отпуснем малко и да обобщим свършеното. Присъединете се към нас в разглеждането на най-новите неща и може би ще разберете малко за предстоящите.

sn-клиент-js 3.0.0

sn-client-js е ядрото — и основната входна точка — на нашите клиентски пакети. Той съдържа логика за взаимодействие с хранилище, удостоверяване, заявки и има вградени типове съдържание в пакет.

Изчистване на концепциите за тип съдържание

Типовете съдържание на Typescript могат да бъдат генерирани от бекенда на ECM на sensenet и са полезни, ако искате да напишете строго въведен Typescript код. В предишните издания Типовете съдържание бяха наследени от класа Съдържание (който е богато представяне на модел на домейн на екземпляр на Съдържание). Например, потребителското наследство изглеждаше така:

Съдържание → GenericContent → Потребител

Сега извлякохме нашия клас Content (сега ContentInternal) от веригата за наследяване и създадохме псевдоним на тип, наречен „Content“ — този е тип Union на *ContentInternal* и посочения тип. Има някои от многото предимства на тази промяна

  • Ако използвате обикновен JavaScript, дори не е нужно да се интересувате от типовете съдържание (освен когато създавате съдържание)
  • Можем да премахнем всички логики от генерираните дефиниции на тип съдържание. Това означава приблизително 1000 реда код :)
  • Използването на ваши собствени потребителски типове съдържание ще бъде много по-лесно. Трябва само да дефинирате нов клас Typescript, който имплементира IContent и можете да го използвате

Схеми, обвързани с хранилище

ContentTypes и Schemas описват съдържание. В момента схемите се използват за динамично генериране и валидиране на формуляри. Схемите – за разлика от ContentTypes – могат да се променят по време на изпълнение. Веднага след като промените дефиниция на тип съдържание (напр. добавите ново задължително поле в старото Изследване или може би в някоя от бъдещите версии на нашия администраторски GUI ;)), ще очаквате, че следващото създадено от вас съдържание ще вземе промяната. В момента се генерират и схеми, но от сега нататък те се използват само като по подразбиране. Екземплярите на хранилището имат свои собствени хранилища за схеми и тяхното съдържание може да бъде заменено. Планираме да добавим функция за презареждане на схема на живо в предстояща версия.

Качване

Добавихме функцията за качване на парчета във версия 2.5.0, сега я подобрихме. Имаме три крайни точки за качване. С repository.UploadFile() можете да качите прост File обект от формуляр или Drop събитие, с repository.UploadTextAsFile() можете да запишете низ като двоичен файл и накрая repository.UploadFromDropEvent() ви позволява да качите цял списък с файлове или поддърво с директории от просто събитие Drop. Събитието за качване работи с rx/js наблюдаеми, така че е лесно да се проследи информацията за напредъка на качването въз основа на завършените парчета. Опциите за качване са разширени с допълнителни OData параметри в тази версия. Те са полезни, ако искате да посочите полета за избор или разширяване, когато качването приключи, така че не е необходимо да презареждате съдържанието на файла ръчно.

Пакетни действия

Пакетните действия (копиране, преместване и изтриване) са подобрени както в задната, така и в предната част. Сега клиентът ще получи подробен отговор — за всяка операция — и може да задейства точно същите събития в хранилището, както при отделни операции. Нека да разгледаме примерния отговор на операцията пакетно копиране.

{  
   "d":{  
      "__count":3,
      "results":[  
         {  
            "Id":101,
            "Path":"Root/Workspace/DocLib",
            "Name":"a"
         }         {  
            "Id":102,
            "Path":"Root/Workspace/DocLib",
            "Name":"b"
         }
      ],
      "errors":[  
         {  
            "content":{  
               "Id":103,
               "Path":"Root/Workspace/DocLib",
               "Name":"C"
            },
            "error":{  
               "code":"NotSpecified",
               "exceptiontype":"Exception",
               "message":{  
                  "lang":"en-us",
                  "value":"Error message value"
               },
               "innererror":{  
                  "trace":"InnerError Trace value"
               }
            }
         }
      ]
   }
}

Горната операция ще задейства две събития repository.Events.OnContentCreated и допълнително repository.Events.OnContentCreateFailed за една HTTP заявка.

Но какво можете да направите с групови операции и „събития в хранилището“?

Представете си някои отделни компоненти (напр. дърво, списък със съдържание и навигационен път, като файлов изследовател), прикрепени към едно и също хранилище и някакъв пакет операции за преместване/изтриване/копиране. Синхронизирането на съдържание може да бъде трудно. Трябва да избягвате допълнителни уеб заявки и повторно стартиране на компоненти, но да ги актуализирате с промените - това е мястото, където събитията в хранилището са полезни. Можете да заредите данните на компонента веднъж и да абонирате за събитие във вашия компонент. След като приключите, можете да обработвате промените постепенно - без допълнителни заявки или презареждания:

OAuth

Добавихме поддръжка на доставчик на OAuth за услугата за удостоверяване на JWT. Това означава, че можете да внедрите и добавите свой собствен OAuth доставчик — точно както го направихме в sn-client-auth-google

sn-client-auth-google 1.0.0

Този пакет е първият ни официален доставчик на OAuth от страна на клиента. Изисква се sensenet ^7.0.0 с инсталиран SN7 OAuth доставчик и проект на Google API конзола. Можете да го използвате със или без официалната Библиотека на платформата на Google или всеки компонент на трета страна, който може да извлече id_token.

Фокусирахме се върху поддържането на тази библиотека ясна и лесна за използване, надяваме се, че можете да я интегрирате в рамките на няколко минути — след като проверите пример в readme.

sn-redux 3.4.0

sn-redux винаги държи под око sn-client-js, ние работим предимно паралелно и ето как се случи този път. Научете как са добавени новите функции и какво и как можете да постигнете с тях.

Качване

Има три нови действия за обработка на нещата, свързани с качването. Един за заявка за качване (може да обработва само един файл наведнъж), един за обработка, ако файлът е качен успешно, и един за неуспешно качване. Функционалността за качване също е внедрена в свързаните редуктори, така че ако е качен нов файл, неговият идентификатор се добавя към масива ids и обектът entities ще съдържа новото съдържание. Разбира се, има нов redux-observable epic, който обработва ajax заявката във фонов режим, така че за да имате функцията за качване, просто трябва да извикате действието за качване:

Actions.UploadRequest(content, file)

Параметър content е родителският обект на съдържание, а file е файлът, който трябва да бъде качен.

Научете повече за качването в sn-redux в API препратки.

Пакетни действия

Отсега нататък пакетните операции се поддържат и в sn-redux с по три нови действия за обработка на заявки, успешни и неуспешни операции. Тъй като отговорите на груповите операции могат да бъдат смесени (някое съдържание може да бъде качено, а друго не), се добавя нов редуктор, наречен batchResponses, за да задържи персонализирания отговор и грешката. На заден план три нови епоса управляват процесите.

Научете повече за пакетните операции в sn-redux в API препратки.

OAuth

Тъй като необходимият доставчик беше готов както в бекенда, така и в sn-client-js, беше задължително да се добави действие за обработка на влизане (и регистрация) с акаунт в Google и в sn-redux. Процесът след влизане обаче е същият, създава се нов епос, наречен userLoginGoogleEpic. Този нов епос е абониран за новото действие за заявка за влизане, но ако е отговорено успешно или ако е било неуспешно, той изпраща същите действия, които се използват в простия процес на влизане.

Какво следва?

Нека видим с няколко думи какво ни чака за зимата:

Пакети npm с обхват

Тъй като sn-client-js започна да расте твърде бързо, ще бъде добра идея да го разделите на няколко пакета. Трябва да променим нашите конвенции за именуване с нашите NPM пакети и да въведем обхват на пакети за @sensenet специфични пакети, точно както го направиха @Material, @angular, @aurelia или @ReactiveX.

Типове съдържание срещу схеми

Тъй като ContentTypes и Schemas като автоматично генерирани класове са групирани заедно и тясно свързани с обекта Repository, не можем да разширим или добавим типове съдържание от различни пакети (sensenet услуги, уеб страници и т.н.). Така че трябва да разпространяваме ContentTypes в отделен пакет в бъдеще, за да позволим добавянето на типове съдържание и схеми без промяна на sn-client-js.

CTD подобрения

Дефинициите на тип съдържание на Sensenet са страхотни, но се нуждаят от фейслифт от време на време. Този път това означава някои големи подобрения като добавяне на решения за групиране на полета, подреждане и някои промени около свойството на иконата за обработка на библиотеки с икони на шрифтове като Материални икони или Страхотен шрифт

Локализация

Ресурсите за низове бяха активирани от страна на клиента чрез вградения механизъм за групиране и обработка на зависимости на Sensenet. Тъй като изграждаме отделни приложения с комуникация чрез OData, трябва да разберем как локализираните низови ресурси могат да бъдат разпределени от sensenet ECM към клиента.

Първоначално публикувано в community.sensenet.com на 29 ноември 2017 г.