block is not a BlockNode v10.5
githubflub opened this issue Β· 8 comments
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
I call convertToRaw using the contentState that gets passed from whatever sends things through the blockRenderMap. (props.children.props.contentState). It throws an error that says 'block is not a BlockNode'
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started: https://jsfiddle.net/stopachka/m6z0xn4r/.
Make a custom block render map.
const SOME_COMPONENT = (props) => {
convertToRaw(props.children.props.contentState);
return whatever;
}
'unstyled': {
element: SOME_COMPONENT
}
What is the expected behavior?
convertToRaw converts the contentState.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
Worked in 10.4, broke in 10.5 (stuff relating to convertToRaw was changed). Mac OS Sierra 10.12.6
Originally, I updated by doing either
npm install --save draft-js@latest
npm install --save draft-js@0.10.5
Those commands weren't good enough. I deleted my node_modules folder, updated package.json manually (to "0.10.5"), and then did npm install. The error went away.
Never mind, this is an issue again. I am also using npm link. So, my top level repo depends on draft-js 10.5 and a linked repo that depends on draft-js 10.5.
@githubflub it's quite hard to understand what your problem is β I think convertFromRaw
is used by most if not all users of Draft.js, and your code snippet isn't readable at all.
Closing since this is an npm/npm link/dependency management issue/ rather than a problem with draft-js@0.10.5
This stackoverflow answer explains this BlockNode error. https://stackoverflow.com/a/34645112
This Medium article describes the problem I was having perfectly https://medium.com/@penx/managing-dependencies-in-a-node-package-so-that-they-are-compatible-with-npm-link-61befa5aaca7
Helpful article on npm link
https://medium.com/@alexishevia/the-magic-behind-npm-link-d94dcb3a81af
This is driving me nuts. I am trying to npm link
to a local clone/fork of react-draft-wysiwyg
but as soon as i try messing with the embed
button it breaks. (block is not a BlockNode).
i've added in webpack config alias, i've matched the peer deps to main project dep.
I've downgraded draftJS to 0.10.4.
Doing that last one gets me a:
1. You may be adding a ref to a function component
2. You may be adding a ref to a component that was not created inside a component's render method
3. You have multiple copies of React loaded
Is there a fix for this? How are we to improve/contribute to draft-js?
@Aid19801 your issue most likely isnβt with Draft.js, but with how you're using npm link
β I wouldn't be surprised if it was the dependency resolution biting you. Itβs an issue with the npm link
workflow in general, nothing specific to what you're doing.
If you want to contribute to Draft.js, you shouldn't need to npm link
it to anything anyway since the repository comes with examples / playgrounds that can be used when making improvements.
if you still want to work on another project with your dev version of Draft.js, I'm pretty sure a combination of the right npm link
options and Webpack config can solve your issues. Alternatively, I'd suggest trying npm pack
, which creates an archive of a package as it would before publication on npm, that you can then npm install path/to/the/archive.tgz
. Itβs more manual actions, but at least you're guaranteed to depend on the Draft.js code in the same way as it would be if it was from the npm registry.
For anyone that reads this in the future, i went with @thibaudcolas suggestion (thanks bro!) npm pack
. It's slow as i have to keep packing, re-installing the local instance to see changes - but it does at least give me a representation of the changes i'm making. Really hope they improve npm/yarn link
soon though. ππ
When you patch convertFromDraftStateToRaw.js
in line 42 you can avoid that issue.
Instead of:
if (block instanceof ContentBlock) {
Use
if (block && block.constructor.name === "ContentBlock") {
Imho it should be "save enough". Would it make sense to set a PR with this?