2016-05-03 9 views
2

Ich verwende Draft.js Editor Komponente. Ich habe einen benutzerdefinierten Block-Renderer korrekt über blockRendererFn prop angegeben. Die Komponente rendert die EditorBlock importiert von draft-js wie in der Draft documentation empfohlen. In den Requisiten, die ich in meinem benutzerdefinierten Blockrenderer bekomme, habe ich nicht die Information, ob der Block schreibgeschützt ist oder nicht. Zumindest nicht standardmäßig. Ich könnte es über blockProps bekommen, aber ich fühle, dass ich etwas vermisse. Wie es sollte natürlich funktionieren, wenn Sie die EditorBlock verwenden. Wie könnte es den readOnly Wert aus dem Kontext oder etwas bekommen.Wie kann ich den benutzerdefinierten gerenderten Block im Draft.js-Editor schreibgeschützt machen, wenn seine readOnly-Prop wahr ist?

Ist es meine Verantwortung, meinen Block ohne die EditorBlock zu rendern, wenn readOnlytrue ist? Und bin ich dafür verantwortlich, den Wert readOnly an meinen benutzerdefinierten Block-Renderer über blockProps weiterzugeben?

Antwort

1

Nun, ich habe dies auf die Flaute antwortete draftjs Team so hier, ich werde es zusammenzufassen:

Es sollte genug sein readOnly auf true setzen alle onChange Rückrufe im gesamten Editor zu verhindern. Mein Problem war eine Art Bug, bei dem ich editable auf true im benutzerdefinierten Block-Renderer gesetzt habe, den ich von blockRendererFn zurückgegeben habe. Dies führte dazu, dass das Flag readOnly außer Kraft gesetzt wurde und somit Änderungen in meinem benutzerdefinierten Block zugelassen wurden. Isaac bezeichnete dies als potenziell unerwünschtes Verhalten.

Die Lösung in meinem Fall war nicht anzugeben, ob mein Block editierbar ist oder nicht auf dem benutzerdefinierten Block-Renderer. Auf diese Weise wird die readOnly richtig berücksichtigt und es gibt nichts mehr, was ich tun musste.