draft.js: making editor content multipage - javascript

I have a difficult problem to solve.
Here is my sample project
Basically I want to create a editable book-like container and since each book page is another container, I can't figure how to make an editor transition from one page to another, once the page is filled with text.
Here is what I'm trying to achieve:
My first thought was to use a shared state for multiple editor instances, but as you can see in the example code, it doesn't work as expected and same text appears in two pages.
How can I achieve a multi-container transition when using draft.js?

The logic in general is to listen to changes of the first editor, count characters / word / lines (or more advanced calculation, if the editor has scroll for example) and finally focus the second editor if needed.
This answer covers, listen, dummy calculation and focus on the next editor.
This answer doesn't cover the calculation itself nor dynamic number of pages nor moving back from second editor when deleting content etc. But I believe that it's a direction to your final goal.
Listen
First of all, I moved the state creation and handling back to the Editor component itself. What "interests" the parent component ("App") is to get notified when its content changed.
But now, App needs to access the ("draft-js") editor in order to call focus. This will solve by creating "ref" in App and propagate it using forwardRef.
const editorRef = React.useRef();
const Editor = React.forwardRef((props, ref) => {
return <MyEditor name="editor-2" forwardRef={ref} />;
});
...
return (
...
<Editor ref={editorRef} />
)
and in Editor.js
function MyEditor({ onChange, forwardRef }) {
...
return (
<Editor
ref={forwardRef}
)
});
Next thing is to add onChange to Editor so App get notified when the content has been changed.
<Editor
ref={forwardRef}
stripPastedStyles
editorState={editorState}
onChange={editorState => {
setEditorState(editorState);
onChange && onChange(editorState); // <---
}}
/>
Handle the change and focus
The first editor is now
<MyEditor name="editor-1" onChange={onEditorChange} />
and onEditorChange is
const onEditorChange = editorState => {
const text = editorState.getCurrentContent().getPlainText();
if (text.length >= 5) {
setTimeout(() => {
editorRef.current.focus();
});
}
};
Currently it checks if the content's length is 5. You probably want to calculate it in a more sophisticated way.
The last question is, why setTimeout? Well, the simple answer is that without it, "draft-js" throw an error. I believe that it's something with their implementation of release / delete / clear global variables or something.
And the most important part, the code and live demo :)
https://codesandbox.io/s/young-shape-t6kcc?file=/src/App.js

Related

How can I use React Material UI's transition components to animate adding an item to a list?

I have this class.
class Demo extends React.Component {
constructor(props) {
super(props);
this.state = {
items: []
};
this.add = this.add.bind(this);
this.clear = this.clear.bind(this);
}
add() {
this.setState(prev => {
const n = prev.items.length;
return {
items: [<li key={n}>Hello, World {n}!</li>, ...prev.items]
};
});
}
clear() {
this.setState({ items: [] });
}
render() {
return (
<div>
<div>
<button onClick={this.add}>Add</button>
<button onClick={this.clear}>Clear</button>
</div>
{/* This is wrong, not sure what to do though... */}
<Collapse in={this.state.items.length > 0}>
<ul>{this.state.items}</ul>
</Collapse>
</div>
);
}
}
Sandbox link: https://codesandbox.io/s/material-demo-ggv04?file=/Demo.js
I'm trying to make it so that every time I click the "add" button, a new item gets animated into existence at the top of the list and the existing items get pushed down. Not sure how to proceed though.
Extra Resources
Example of what I'm trying to achieve: https://codeburst.io/yet-another-to-do-list-app-this-time-with-react-transition-group-7d2d1cdf37fd
React Transition Group Transition docs: http://reactcommunity.org/react-transition-group/transition (which seem to be used internally by Collapse)
I updated your Sandbox code to achieve what you wanted, but I don't think MaterialUI is the best library for that (I could be missing a better way to do it).
The challenge is that when you add a new item, that doesn't exist in the DOM yet. And most of those animation libraries/components require the element to be in the DOM and they just "hide" and "show" it with a transition time.
I had a similar situation and after some research, the better library I found that can handle animation for elements that are not yet in the DOM, was the Framer Motion. (You can check their documentation for mount animations)
Anyway, here is the link for the new Code Sandbox so you can take a look. The changes I made:
Removed random key
In the map function that creates your list using the <Collapse /> component, there was a function to get a random integer and assign that as a key to your component. React needs to have consistent keys to properly do its pretenders, so removing that random number fixes the issue where your "Toggle" button wasn't animating properly. (If your list of items doesn't have an unique ID, just use the index of the map function, which is not a good solution, but still better than random numbers).
<Collapse key={i} timeout={this.state.collapseTimeout} in={this.state.open}>
{it}
</Collapse>
Added a new function to control the toggle
The approach here was: add the item in your list and, after the element is in the DOM, close the <Collapse />, wait a little bit and open it again (so you can visually see the animation). In order to do that, we needed a new "toggle" function that can explicit set the value of the collapse.
toggleValue(value) {
this.setState(() => {
return {
open: value
};
});
}
Added a variable timeout for the collapse
The last issue was that, closing the <Collapse /> when the new item is added, was triggering the animation to close it. The solution here was to dynamically change the timeout of the collapse, so you don't see that.
setCollapseTimeout(value) {
this.setState(() => {
return {
collapseTimeout: value
};
});
}
When adding the element to the list, wait to trigger the animation
Again, to work around the issue with elements not yet in the DOM, we need to use a setTimeout or something to wait to toggle the <Collapse />. That was added in your add() function.
add() {
this.toggleValue(false);
this.setCollapseTimeout(0);
this.setState(prev => {
const n = prev.items.length;
return {
items: [<li key={n}>Hello, World {n}!</li>, ...prev.items]
};
});
setTimeout(() => {
this.setCollapseTimeout(300);
this.toggleValue(true);
}, 100);
}
Again, this is a hacky solution to make <Collapse /> from MaterialUI work with elements that are not yet in the DOM. But, as mentioned, there are other libraries better for that.
Good luck :)
Ended up here earlier on and then came back to create a sandbox showing hopefully a simple method for this scenario. The material-ui docs are a bit (lot) light in this area and I was fighting with a very similar situation, but I tried something with TransitionGroup from react-transition-group, crossed my fingers and it seemed to work.
Forked CodeSandbox with TransitionGroup
The gist is that you
wrap all of the components you want to transition in the <TransitionGroup> component
Inside the TransitionGroup, put in the "condition" (logic or loop output) for the data you want to render
Wrap the individual components you want to transition with transition component of your choice - <Collapse> in this example
e.g. In its most simple setup where "items" is an array of unique numbers coming from either props, state or a redux store
<TransitionGroup>
{items.map(item => (
<Collapse key={item}>
I am item {item}
</Collapse>
))}
</TransitionGroup>
With this setup I have found that I didn't need to put any props on the TransitionGroup or Collapse, and the TransitionGroup handled all the mounting and unmounting in the loop rendering. Material UI doesn't produce the lightest of HTML output, but I guess it's all rendered on the fly so maybe that makes it better (unless you have thousands of elements, then things start to drag).
You can even go a step further and wrap the whole thing in another TransitionGroup to cover situations where you want to remove the whole thing without transitioning all of the individual items - in this instance I switched it to a <Slide>. I was absolutely certain that this wouldn't work, but it seemed to not care. You can also try and be semantic and use the "component" property rather than wrapping in another element e.g.
{items.length > 0 && (
<TransitionGroup>
<Slide>
<TransitionGroup component="ul">
{items.map((item) => (
<Collapse component="li" key={item}>I am item {item}</Collapse>
))}
</TransitionGroup>
</Slide>
</TransitionGroup>
)}
I have changed the sandbox in the following ways
Included TransitionGroup from react-transition-group
Changed the "add" logic so that the components aren't part of the "items" array - the array only contains the data required to render the components
I have added a simple "count" and pushed that to the array to give the items a unique index (had originally used Math.random, but I wanted a "prettier" output). Generally your items will probably be coming from a database somewhere where a unique id will already be set.
Rendered the components in a loop based on the data in the array (this could be done in a separate function, but the gist is that the components aren't being stored in the array)
added a "delete" function to show the removal of single items
wrapped the whole group in a second <TransitionGroup> to show that the unmounting can happen in a group level
Put in some simple styling to get a better idea of the effect. You could use Material UI components here, but just wanted to keep it simple.
Hope this helps someone in the future.

Using the hidden attribute vs conditionally rendering a component

I have recently discovered an alternative to conditionally rendering a component in JSX, which is to use the hidden HTML attribute.
Example
function Parent() {
return {!hideChild && <Child />}
}
vs
function Parent() {
return <Child hidden={hideChild} />
}
function Child({ hidden }) {
return (
<div hidden={hidden} >
//my content
</div>
)
}
So far I have not noticed any performance or alike issues when using hidden. In saying that, are there any downsides to have lots of HTML on the page that is hidden?
For me, this approach has served well when I want to retain the component state and have the functionality of toggling the visibility of the components UI.
Is this bad practice? Should we be conditionally rendering components instead?
The difference is that when using conditional rendering, the logic inside the conditionally rendered UI will not be executed if the condition fails.
But using the hidden attribute will execute the logic but only hides the UI.
Example:
import React from 'react';
const A = () => {
console.log('A rendrerd');
return <h1>A</h1>;
};
const B = ({ hidden }) => {
console.log('B rendrerd');
return <h1 hidden={hidden}>B</h1>;
};
const Test = () => {
return (
<div>
{false && <A />}
<B hidden={true} />
</div>
);
};
export default Test;
A will never call its console.log statement.
B is hidden but it will log B rendered.
I think this is worth mentioning. hidden attribute acts more or less like display: none with css. The truth is "the component will be rendered but only hidden from your display."
Just to illustrate, below is a photo of some html and their output. you realize that the output doesn't show the <p> that is decorated with hidden attribute but if when you inspect the rendered code, you realize that <p> was actually renderd. So you can image have multiple components in react where they will all be rendered but only displayed based on that hidden attribute.
Well I may not be sure of the performance involved but it's obvious that doign a simple if() to condition render a component will depending on the size of your components be much quicker than rendering everything and only relying on their hidden attribute decoration. And this also means that a user can just Inspect element and remove hidden attribute to display that component which is intended to be hidden.

React replace event.target with input

UPDATE
Here's are some demos
contentEditable demo - requires double click for H1 to become editable
replace with input demo - adopts event.target styles but makes the UI 'twitch' when rendered
So I have some functional components, let's say:
component1.js
import React from 'react';
const component1 = props => (
<div>
<h1>Title</h1>
</div>
);
export { component1 };
They are variable. event.target could be anything with text, so paragraph, heading, anything. I'm trying to let users edit content inline by clicking on it, so I'll pass a function editMode to these functional components, that'll update parent state with editing info, let's say like this:
<h1 onClick={event => {editMode(event, props.name, props.title, 'title')}}>title</h1>
This changes parent local state to have all the necessary information to grab the value from redux, define a target etc. For this example, props.name is the name of the component, props.title is the value, and 'title' is object key in redux.
So I'll add something to my component1.js and make it look a bit like this:
import React from 'react';
const component1 = props => (
<div>
{props.editState === 'true' &&
<EditLayout
name={props.name}
target={props.target}
value={props.value}
onChange={event => someFunc(event)}
/>
}
<h1>Title</h1>
</div>
);
export { component1 };
Now this works fine, except it doesn't scale. EditLayout, in this case, will just return an input with correct value. What I need it to do is to adapt to whatever is being clicked, get font size, background, padding, margin, position. Am I doing this right? Every way I try, I run into huge issues:
Idea 1 - move EditLayout component outside of the functional component
Issue: positioning
So I'll move EditLayout to parent component that contains both component1.js and EditLayout. This will allow me to manipulate it from inside the functional component, without having to include it everywhere. I'll then grab coordinates and other important information from event.target like so:
const coords = event.target.getBoundingClientRect();
const offsetX = coords.left;
const offsetY = coords.top;
const childHeight = coords.height;
const childWidth = coords.width;
const childClass = event.target.className;
I'll then wrap the EditLayout to return a container which contains an input, and apply size/coordinates to the absolutely positioned container. This'll present an issue of input being offset by a random amount of pixels, depending on how big/where is the event.target.
Idea 2 - pass relevant computed styles to EditLayout
Issue: twitching on render, and I have to add EditLayout for every possible event.target there is, as well as condition its' render
So I'll grab all important computed styles like this:
const computedTarget = window.getComputedStyle(event.target);
const childMargins = computedTarget.marginBottom;
const childPaddings = computedTarget.padding;
const childFontSize = computedTarget.fontSize;
const childTextAlign = computedTarget.textAlign;
And pass it to component1.js, and then pass it to EditLayout component inside the component1.js. I'll then condition theevent.target to hide if it's being edited like this:
<h1 className={ props.target === 'title' ? 'd-none' : ''}>Title</h1>
And condition the EditLayout to show only if it's needed:
{props.target === 'title' && <EditLayout />}
In this example, clicking h1 will show the input, but the layout itself with twitch on render. Input will have the exact same margin and font size as the h1, or event.target, but it'll appear bigger and extend the layout. Demo:
Idea 3 - Use conditional contentEditable
Issue: Requires double click to enable, doesn't work in safari, doesn't let me preselect the value
This is the weirdest of them all. I figured it'd be pretty simple, do something like this inside the functional component render:
<h1 contentEditable={props.target === 'title'} onClick={event => props.setTarget(event)}>Title</h1>
However, I have to double click to enable it. I have no idea why, if I attach a console log every time onClick is fired, I'll get correct outputs, I'll get the correct target value as well. I've tried numerous ways, but it simply requires double click. Even attempted to handle this inside the functional component, as most of the stuff is handled by a parent component, doesn't make a difference.
I have oversimplified the examples, so it's safe to assume/understand the following:
I am passing props in a correct fashion, they aren't undefined
I am using bootstrap
I am using styled components, and EditLayout is a styled component
which accepts props and turns them into CSS like: font-size: ${props
=> props.fontSize};
The values should be correct, I am not manipulating anything I get back from getComputedStyle() or getBoundingClientRect()
I am keen on keeping my functional components functional, and easy to
add. Functional components, in this case, are simple HTML structures,
and I'd like to keep them as simple as possible
So there's a neat solution to contentEditable requiring two clicks instead of one, instead of binding onClick and passing it to enable contentEditable, simply keep contentEditable true and handle the change however you like. Here's a working h1 that doesn't require two clicks to enable contentEditable, unlike the one in the demo
<h1
className="display-4 text-center"
contentEditable
suppressContentEditableWarning
onBlur={event => updateValues(event)}
>
Title
</h1>
The available methods for trigger update could be onBlur or onInput.

ReactJS loosing reference of an element

I am forcing element to be focused like this
/**focusing the element if the element is active */
componentDidUpdate() {
console.log(this.activeElementContainer);
if(this.activeElementContainer!==undefined && this.activeElementContainer!==null) {
/** need to focus the active elemnent for the keyboard bindings */
this.activeElementContainer.focus();
}
}
My render has conditional rendering the elements are being rendered dynamically from the array,
Let say I have one element in div and I am adding another from the toolbox. In that case I need to focus the last element I dragged.
render() {
let childControl= <span tabIndex="-1" dangerouslySetInnerHTML={{__html: htmlToAdd}}></span>;
if(this.props.activeItem){
childControl=<span ref={ (c) => this.activeElementContainer = c }
tabIndex="0" dangerouslySetInnerHTML={{__html: htmlToAdd}}></span>
}
//later I ma using childControl to array and it works fine.
The logs says, first time it works fine
But, second time the this.activeElementContainer is undefined
Is there any alternative way or possible solution to this?
The thing is I need to focus only one element at the time.
Remember: Activecontrol has too many things to do like it can have right click menu, drag etc. so, I need to render it separately.
After reading this one github:
This is intended (discussed elsewhere) but rather unintuitive
behavior. Every time you render:
<Value ref={(e) => { if (e) { console.log("ref", e); }}} /> You are
generating a new function and supplying it as the ref-callback. React
has no way of knowing that it's (for all intents and purposes)
identical to the previous one so React treats the new ref callback as
different from the previous one and initializes it with the current
reference.
PS. Blame JavaScript :P
Source
I changed my code to
<span id={this.props.uniqueId} ref={(c)=>
{if (c) { this.activeElementContainer=c; }}
} tabIndex="0" dangerouslySetInnerHTML={{__html: htmlToAdd}}></span>
Adding if was the real change. now, it has a ref.
For others who face this problem:
I need to write custom function too, in the componentDidUpdate I am still getting old reference,
ref={(c)=>{if (c) { this.activeElementContainer=c; this.ChangeFocus(); }}
Adding this was the perfect solution for me

scrollToRow result is off for dynamic height list

First off, let me provide a little background on my use case for react-virtualized. I am using it together with the v2.0 beta version of react-pdf in order to build a pdf viewer that can handle displaying/rendering pdf documents with a lot of pages more efficiently. An important requirement is that the pdf viewer is fully responsive and can handle documents that have pages that possibly have differing heights.
I have managed to combine both packages (there are a couple of minor react-pdf related hickups), but there are a couple of things that don't quite work like I would expect. Most noticeably, scrolling to a specific row (i.e. page) doesn't really work too well. To give an example, if I attempt to scroll to page index 81 (approximately the middle of my 152 page test pdf) from page index 0, I end up somewhere midway between the desired page and the next page. If I attempt to scroll to the last page index (p.i. 151) I end up at the next to last page.
I am using a combination of WindowScroller, AutoSizer, CellMeasurer and List to create my viewer (I have omitted parts that don't matter directly):
class Viewer extends Component {
constructor(props) {
super(props);
this.state = {pdf: null, scale: 1.2};
this._cache = new CellMeasurerCache({defaultHeight: 768, fixedWidth: true});
}
...
handleResize() {
this._cache.clearAll(); // Reset the cached measurements for all cells
}
updatePageIndex(index) {
this._cache.clearAll();
this._list.scrollToRow(index);
}
rowRenderer({key, index, style, parent}) {
return (
<CellMeasurer cache={this._cache} columnIndex={0} key={key} parent={parent} rowIndex={index}>
{
({measure}) => (
<div style={style}>
<Page
onLoadSuccess={measure}
renderTextLayer={false}
pdf={this.state.pdf}
pageNumber={index + 1}
scale={this.state.scale} />
</div>
)
}
</CellMeasurer>
);
}
render() {
...
<Document
file="./some_pdf_document.pdf"
loading={<Loader />}
error={this.renderError()}
onLoadSuccess={this.onDocumentLoadSuccess.bind(this)}
>
<WindowScroller onResize={this.handleResize.bind(this)}>
{
({height, isScrolling, onChildScroll, scrollTop}) => (
<AutoSizer disableHeight>
{
({width}) => (
<List
autoheight
height={height}
width={width}
isScrolling={isScrolling}
onScroll={onChildScroll}
scrollToAlignment="start"
scrollTop={scrollTop}
overscanRowCount={5}
rowCount={this.state.pdf.numPages}
deferredMeasurementCache={this._cache}
rowHeight={this._cache.rowHeight}
rowRenderer={this.rowRenderer.bind(this)}
style={{outline: 'none'}}
ref={ref => this._list = ref} />
)
}
</AutoSizer>
)
}
</WindowScroller>
</Document>
}
}
...
Is what I do in updatePageIndex() correct or is there still something missing?
I think there's a misunderstanding or two above. Firstly, calling cache.clearAll() will erase all measurements- requiring CellMeasurer to recompute them all on the next render. Unless something has changed that invalidates these measurements- (which doesn't seem to be the case from your description)- then you wouldn't want to do this. This method should only be called if a measurement may be invalid due to a change like a browser width resize that might affect the height of wrapping text content, etc.
Secondly, if you do need to call cache.clearAll() then you will also want to call list.recomputeRowHeights(). CellMeasurer caches measurements (sizes) and List caches positions (offsets). This lets data be re-ordered (eg sorted) without requiring re-measurement. All that's needed after a sort is for List to recompute its positions.
Check out this code snippet from a Twitter-like demo app I built with react-virtualized for an example of how this is done.
If the above info doesn't help you resolve matters, leave a comment and a repro on CodeSandbox or similar and I'll take a look.
The only way I got this to work properly (i.e. scroll to the right page) was to use the scrollToIndex property of the List component. Setting that to a certain row index strangely enough does scroll to the right page.
Only problem with using scrollToIndex is that it doesn't allow you to scroll back up past the scroll index. My workaround is to set the index back to -1 after the scroll has completed. However, if I do this too quick, scrollToIndex also scrolls to the wrong row. The only way I managed to get around this is to set the index to -1 using setTimeout(). Very hacky, but it does the trick. I tried other ways using componentDidUpdate() and a promise, but none of them worked for me.

Categories