Netlify-cms: "TypeError: e.get is not a function" when an editor widget has a nested list

Created on 22 May 2018  路  9Comments  路  Source: netlify/netlify-cms

- Do you want to request a feature or report a bug?

bug

- What is the current behavior?

I have a custom editor component that encapsulates some structured data, particularly a list field with a markdown widget inside it: https://github.com/papandreou/netlify-test-2/blob/e91791c56ecb441d0867a79f66e79aa678bfd995/admin/index.html#L65-L71

This appears to work fine in the editor when I create a new component. The markdown editor expands correctly, and I can add all the learnings I want, and expanding/collapsing the widget works fine. When I publish, it also serializes to the format that I would expect: https://raw.githubusercontent.com/papandreou/netlify-test-2/master/lessons/2018-05-22-my-new-lesson.md

However, when I load the document again (or switch to markdown mode and back) and try to expand the custom widget, the following error happens, similar to #1353:

react-dom.production.min.js:164 TypeError: e.get is not a function
    at t.value (ListControl.js:204)
    at Hn.renderItem (ListControl.js:245)
    at Array.map (<anonymous>)
    at ListControl.js:47
    at beginWork (react-dom.production.min.js:132)
    at r (react-dom.production.min.js:161)
    at i (react-dom.production.min.js:161)
    at a (react-dom.production.min.js:162)
    at k (react-dom.production.min.js:169)
    at _ (react-dom.production.min.js:168)

From debugging a bit, I can tell that the fromBlock method of my custom widget returns the following, which appears to be correct:

{
  "foobars": [
    {
      "foobar": "Here is **one** foobar"
    }
  ],
  "image": "/images/uploads/screen-shot-2018-02-26-at-15.18.22.png",
  "title": "the title"
}

- If the current behavior is a bug, please provide the steps to reproduce.

It seems like the error is reproducible in a simpler setting that does not depend on my custom patches or the markdown widget, so the steps are:

  1. Declare a custom editor component:
CMS.registerEditorComponent({
  // Internal id of the component
  id: "SimpleListWidget",
  // Visible label
  label: "SimpleListWidget",
  // Fields the user need to fill out when adding an instance of the component
  fields: [
    {name: 'foobars', label: 'Foobars', widget: 'list', fields: [
      {name: 'foobar', label: 'Foobar', widget: 'string'}
    ]}
  ],
  // Pattern to identify a block as being an instance of this component
  pattern: /^SimpleListWidget (\S*)/,
  // Function to extract data elements from the regexp match
  fromBlock: function(match) {
    var obj = {
      foobars: []
    }
    match[1].split(',').forEach(function (foobar) {
      if (foobar !== '') {
        obj.foobars.push({foobar: foobar});
      }
    });
    return obj;
  },
  // Function to create a text block from an instance of this component
  toBlock: function(obj) {
    return 'SimpleListWidget ' + (obj.foobars || []).map(entry => entry.foobar).join(',');
  },
  // Preview output for this component. Can either be a string or a React component
  // (component gives better render performance)
  toPreview: function(obj) {
    return (
      'Here is my SimpleListWidget with ' + JSON.stringify(obj)
    );
  }
});
  1. Open the editor and add a SimpleListWidget to a markdown field in rich text mode
  2. Click "Add Foobar +" and enter some text
  3. Switch to markdown mode
  4. Switch back to rich text mode

- What is the expected behavior?

That the SimpleListWidget ... block turns back into a component in rich text mode.

- Please mention your versions where applicable.

Netlify CMS version: 1.8.0
Browser version: Chrome 66.0.3359.181/OSX

Node.JS version: 9.5.0 (but doesn't matter as this happens in the browser)
Operating System: OSX

- Please link or paste your config.yml below if applicable.

https://github.com/papandreou/netlify-test-2/blob/1503df31b0cdc59db5739dd846c038db80221858/admin/config.yml

extensioneditor-components bug pinned confirmed

Most helpful comment

I just came here to open an issue for the same problem, great that I found this and you're also providing a work around.

I was going around in circles trying to debug this convinced the problem was at my end.

I agree with @papandreou that ideally this transformation would be handled by the framework.

All 9 comments

Hadn't tried using lists in an editor component, thanks for raising this.

The issue is that the List widget expects an Immutable List of Immutable Maps for it's values - instead of ['foobar value'], it wants List[ Map({ foobar: 'foobar value' }) ]. We should be handling this transformation in the widget I _think_, but not certain.

For now, you can fix your widget implementation with the following updates:

  • Make sure Immutable loaded and ready.

  • Change your fromBlock function to something like:

fromBlock: function(match) {
  const foobars = match[1].split(',').filter(val => val).map(foobar => ({ foobar }));
  const obj = {
    foobars: Immutable.fromJS(foobars)
  }
  return obj;
}
  • Change your toBlock function to something like:
toBlock: function(obj) {
  const foobars = Immutable.fromJS(obj.foobars || [])
  return 'SimpleListWidget ' + (foobars.map(entry => entry.get('foobar')).join(',');
},

@erquhart, thanks a lot for the quick reply and the workaround -- I have my original, more complex custom editor widget working now based on it.

I agree that the transformation should be handled by the framework, though.

I just came here to open an issue for the same problem, great that I found this and you're also providing a work around.

I was going around in circles trying to debug this convinced the problem was at my end.

I agree with @papandreou that ideally this transformation would be handled by the framework.

I get this error when nesting lists using the default list widget. Edit: never mind it was related to this: https://github.com/netlify/netlify-cms/issues/1353.

I had a similar issue and was down to the fact I was using an object widget with just one field.

thumbnails:
    display: true

had to change to

display_thumbnails: true

Which makes a millions times more sense anyway.

Hope this helps someone that made the same mistake as myself.

:100:

Thanks for adding that @kylekirkby!

Actually leaving this open, should be supported out of the box.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Any updates on this? The bug is affecting me as well... A fix would be nice!

Was this page helpful?
0 / 5 - 0 ratings