SJRK-318: The toc header is showing "[Object Object]" when the initial language is set to Spanish

Description

Steps to reproduce the problem:

1. Check out @@Gregor Moss's SJRK-255 branch - https://github.com/BlueSlug/sjrk-story-telling/tree/SJRK-255
2. In SJRK root directory, copy the file sjrk.storyTelling.server.config.json5.example to sjrk.storyTelling.server.config.json5
3. Modify sjrk.storyTelling.server.config.json5 to set the value of "theme" to an empty string;
4. Open a powershell window, run these commands to start SJRK site:

docker run -d --name sjrk-couchdb couchdb:latest
docker run -p 5984:5984 -d couchdb
node src/server/db/dbSetup.js
node index.js

5. Access http://localhost:8081/ in a browser to open SJRK website
6. Open UIO to turn on the table of content. TOC shows up and the header "table of content" is showing correctly
7. Click the link "Español" at the top right corner to switch to Spanish. The TOC header switches to correct language in Spanish
8. Refresh page. The TOC header now shows the wrong "[Object Object]". See attached 1.png
9. Click "English" link to switch the language. The TOC header continues showing as "[Object Object]"

My debugging so far shows:
1. TOC will be recreated every time at a locale change - https://github.com/fluid-project/sjrk-story-telling/pull/35/files#diff-8d2014003434d9502a4871590ada6c4eR35-R43
2. At TOC recreation, it fetches the header from "{messageLoader}.resources.tocMessage.parsed.tocHeader" - https://github.com/amb26/infusion/blob/FLUID-6145/src/framework/preferences/js/Enactors.js#L467
3. When the initial language is "en", "{messageLoader}.resources.tocMessage" is populated correctly, see attached 2.png
4. However, when the initial language is "es", "{messageLoader}.resources.tocMessage" seems in an earlier form that the needed messages are still in "{messageLoader}.resources.tocMessage.resourceSpec" instead of one level up. 3.png shows the structure in "tocMessage" and 4.png shows with the expanded "tocMessage.resourceSpec"

Attachments

Comments

• Antranig Basman commented 2019-12-16T08:23:36.090-0500

  I had a go at reproducing this but ran into a prior problem with the fluid-couch-config module. The error performing the dbSetup was as follows:

  e:\Source\gits\sjrk-story-telling>node src\server\db\dbSetup.js
  Infusion at path e:\Source\gits\sjrk-story-telling\node_modules\infusion is at top level
  13:15:20.890:  Registering module sjrk-story-telling from path e:\Source\gits\sjrk-story-telling\
  13:15:20.891:  Registering module infusion from path e:\Source\gits\sjrk-story-telling\node_modules\infusion\
  13:15:20.892:  Registering module infusion from path e:\Source\gits\sjrk-story-telling\node_modules\infusion
  Resolved infusion from path e:\Source\gits\sjrk-story-telling\node_modules\kettle\node_modules\infusion\src\module to e:/Source/gits/sjrk-story-telling/node_mod
  ules/infusion
  13:15:20.994:  Registering module kettle from path e:\Source\gits\sjrk-story-telling\node_modules\kettle
  13:15:21.372:  Resolved infusion from path e:\Source\gits\sjrk-story-telling\node_modules\fluid-couch-config\node_modules\infusion\src\module to e:/Source/gits/
  sjrk-story-telling/node_modules/infusion
  13:15:21.387:  Registering module fluid-couch-config from path e:\Source\gits\sjrk-story-telling\node_modules\fluid-couch-config
  13:15:21.420:  Making sure DB _users exists in Couch instance at http://localhost:25984
  13:15:21.752:  Making sure DB _replicator exists in Couch instance at http://localhost:25984
  13:15:21.776:  Making sure DB _global_changes exists in Couch instance at http://localhost:25984
  13:15:21.801:  Making sure DB stories exists in Couch instance at http://localhost:25984
  13:15:21.861:  DB _users exists
  13:15:21.862:  No documents to update
  13:15:21.862:  No documents to update
  13:15:21.863:  SUCCESS
  13:15:21.865:  DB stories exists
  13:15:21.866:  Updating document at stories/_design/stories
  13:15:21.869:  DB _global_changes exists
  13:15:21.869:  No documents to update
  13:15:21.869:  No documents to update
  13:15:21.869:  SUCCESS
  13:15:21.870:  DB _replicator exists
  13:15:21.870:  No documents to update
  13:15:21.870:  No documents to update
  13:15:21.870:  SUCCESS
  13:15:21.877:  Existing document _design/stories found
  13:15:21.877:  Document _design/stories unchanged from existing in CouchDB, not updating
  13:15:21.878:  Updating document at stories/storyExample
  13:15:21.882:  Existing document storyExample found
  13:15:21.882:  Document storyExample has been changed, attempting to update
  13:15:21.883:  FATAL ERROR: Uncaught exception: Cannot add property _rev, object is not extensible
  TypeError: Cannot add property _rev, object is not extensible
      at e:\Source\gits\sjrk-story-telling\node_modules\fluid-couch-config\src\couchConfig.js:266:26
      at Request._callback (e:\Source\gits\sjrk-story-telling\node_modules\nano\lib\nano.js:217:16)
      at Request.self.callback (e:\Source\gits\sjrk-story-telling\node_modules\request\request.js:185:22)
      at Request.emit (events.js:182:13)
      at Request.<anonymous> (e:\Source\gits\sjrk-story-telling\node_modules\request\request.js:1161:10)
      at Request.emit (events.js:182:13)
      at IncomingMessage.<anonymous> (e:\Source\gits\sjrk-story-telling\node_modules\request\request.js:1083:12)
      at Object.onceWrapper (events.js:273:13)
      at IncomingMessage.emit (events.js:187:15)
      at endReadableNT (_stream_readable.js:1094:12)
      at process._tickCallback (internal/process/next_tick.js:63:19)
  

  It looks like fluid-couch-config needs to be updated for the FLUID-6145 immutable options scheme since it attempts to store mutable couch documents in its own options as so:

  fluid.defaults("fluid.couchConfig", {
      gradeNames: "fluid.component",
      couchOptions: {
          couchUrl: "http://localhost:5984",
          dbName: null, // To be provided
      },
      dbDocuments: {
          // An object whose keys are the IDs of documents to
          // be created in the database, and the values are the documents
          // themselves.
      },
  

  It's unclear why these are stored in options at all since they don't seem to be read again by anything in couchConfig.js after they are updated in fluid.couchConfig.action.updateSingleDocument . A better model might be to resolve them from the returned promise value rather than mutating them in place in the argument list.

• Antranig Basman commented 2019-12-16T17:48:48.473-0500

  Framework bug filed as https://issues.fluidproject.org/browse/FLUID-6442