Reparenting API

View formatted RFC
Terminology and naming for the createReparent function are up for discussion.

Does this RFC suggest that React would move around the actual DOM nodes? Is it actually possible? For example, if one of the child node was a playing <video> element, by removing it from DOM and reinserting into a different parent, would it still be playing?

@streamich Yes, DOM nodes would be detached with removeChild if the reparent tree is not rendered, and re-inserted later with appendChild/insertChild when added back.
If one of the children of the reparent is a video element this does imply that the video element inserted in the other parent would be the exact same video element.
I cannot make guarantees however about the video still playing. Even if you keep the same instance of the dom node, some DOM elements have quirks when you move them around the dom tree. I'm not proposing any special hacks to handle that. So the video will be the same, but if videos stop playing when you appendChild them into another parent then videos will stop playing when you reparent them.
Though on the topic of playing videos. Take a look at my other "registered prop as ref" RFC, one of my examples is a custom Playing implementation. Which would make the video element a controlled component in regards to playing (like how inputs are controlled when you pass a value to them). Theoretically if you reparented a video with a controlled Playing attribute then even if the browser stopped it the controlled nature would make it resume after it is reparented (though you might have to ignore a pause event if the browser fires one).

...if you reparented a video with a controlled Playing attribute then even if the browser stopped it the controlled nature would make it resume after it is reparented...

I think it resets the currentTime, too.

I think it would reset the currentTime of the video, too.

Well. If you really wanted. You could build a <Video> component which would make all the state in a <video> tag controlled (playing, currentTime, etc...) in the normal way for react (register events to keep state up to date like firing setState every time the video time change, map things to props and change them when props change, etc...). Then this RFC would guarantee that if your <Video> was reparented the React component would stay intact with all its state and in componentDidUpdate you could ensure that any controlled state that the browser reset from the reparent would be restored by your Video component.

@dantman The whole point of reparenting is to keep intact all and any of the states of element that are not controlled by React.

@streamich Yes, it's as simple as appendChild on a component that is already appended somewhere else, without any removeChild calls.

I guess, for React just re-parenting and leaving it up to the user to deal with consequence is fine as long it is opt-in. Here is a short list of consequences:

<video> will stop and lose its state
<audio> will stop and lose its state
 will be reloaded
Any focused elements will lose their focus?
Very important one: any .swf Flash players will reload 🤣
Pobably a bunch of other things will lose their state or reload.

Seems to have some overlap with #7? dangerouslyRecycleNodesounds like a similar concept to me, though I admit I haven't deeply read through either proposal.

@polkovnikov-ph
There are dom states that do not get discarded when you call removeChild on them. And the ability to retain React Components while reparenting is just as important.
But my intent with mentioning removeChild is for the situations where you intentionally detach a tree and hold on to a reference to later mount it.
class MyComponent extends Component {
  content = React.createReparent(this);

  render() {
    const {show, children} = this.props;
    const content = this.content(<Fragment>{children}</Fragment>);

    if ( show ) {
      // Show the contents
      return content;
    } else {
      // Don't render the contents, the dom/component tree will not be
      // present in the page but it will be retained as a detached tree
      // and later re-used when `show` becomes true again.
      return null;
    }
  }
}

If you move a dom node from one parent to another in a render such that the reparent is never left out of the react component tree, I do think it would be ideal for React to just use appendChild/insertChild to move the node instead of using removeChild and then inserting it in the new parent.
If there are dom states that get discarded when you removeChild->appendChild in the same tick but not when you just appendChild. I can add a note to the design/implementation section noting that the implementation should not use removeChild unless the tree is actually being detached and should only use appendChild/insertChild calls when it is only necessary to move dom nodes.
I can also add a limitations section noting the dom nodes that lose state when you reparent them with appendChild.
Would that be sufficient?

I'm unsure, but it seems that it's possible to create a loop of reparenting components that locally looks as if it's possible to use only appendChild on them, but it actually requires at least one removeChild to break the loop. I'm too tired today to convert this idea of counterexample into code tho :/

To dive more into this issue of removeChild/appendChild and state loss I've built a series of simple dom reparent tests that will reparent an element using just appendChild, removeChild + appendChild, and using a delay before re-insertion. Feel free to propose other elements
https://dantman.github.io/dom-reparent-tests/
Summary

Chrome is the only browser that pauses video/audio when you reparent something with appendChild
Firefox and Safari won't even pause the video when you removeChild+appendChild, until you put a delay between the calls, they'll just keep playing the video at the new position
IE11 was the only browser that had any difference between appendChild and removeChild+appendChild – pausing the video when you removeChild+appendChild. Though given that Chrome always pauses, this is actually better than Chrome!
Absolutely none of the browsers I tested lost the current position of the video, even when the video was detached from the tree and a delay was used before putting it back. The suggestion that currentTime gets reset seems to be invalid.
iframes do reload in all browsers, no matter what. This is just a limitation that will have to be accepted for iframes as even just using appendChild without removeChild makes no difference.
Likewise scroll positions are the same, they always reset and you cannot avoid it by just using appendChild. Please see RFC #33, it suggests a new API that solves the scroll issue for normal content updates and potentially could also be used to retain scroll state when reparenting. It may even work for retaining other states like focus and selection.

Conclusion
It would be nice to still note that React should try to use appendChild without first using removeChild if it does not need to. However this actually isn't a big deal. In practice it appears that almost nothing is lost during removeChild that is not lost during appendChild (as long as you re-insert within the same tick). The only difference I could find is that IE11 will pause the video when you removeChild+appendChild but not appendChild. But this is a pretty pointless difference because Chrome pauses the video on even a basic appendChild, so you are going to have to make the playing state a controlled behaviour anyways.
Results

Chrome
append
remove+append
delay

video
pauses, but doesn't lose position
pauses, but doesn't lose position
pauses, but doesn't lose position

audio
pauses, but doesn't lose position
pauses, but doesn't lose position
pauses, but doesn't lose position

iframe
refreshes
refreshes
refreshes

scroll
loses scroll position
loses scroll position
loses scroll position

Firefox
append
remove+append
delay

video
does not pause or lose position
does not pause or lose position
pauses, but doesn't lose position

audio
does not pause or lose position
does not pause or lose position
pauses, but doesn't lose position

iframe
refreshes
refreshes
refreshes

scroll
loses scroll position
loses scroll position
loses scroll position

Safari
append
remove+append
delay

video
does not pause or lose position
does not pause or lose position
pauses, but doesn't lose position

audio
does not pause or lose position
does not pause or lose position
pauses, but doesn't lose position

iframe
refreshes
refreshes
refreshes

scroll
loses scroll position
loses scroll position
loses scroll position

IE11
append
remove+append
delay

video
does not pause or lose position
pauses, but doesn't lose position
pauses, but doesn't lose position

audio
could not test with .wav
could not test with .wav
could not test with .wav

iframe
refreshes
refreshes
refreshes

scroll
loses scroll position
loses scroll position
loses scroll position

Important discussion points:
Is it possible to hydrate a server-rendered DOM tree and know, without needing deterministic IDs, and know what portion of it belongs to a Reparent and should be detached and held on to when unmounting instead of destroyed? (Or would we need to wait for the internals of https://github.com/reactjs/rfcs/pull/32 to solve this)
Should the reparent function (this.header(children)) accept multiple children with a spread, the same way createElement accepts multiple children? These would simply be passed on to createElement, so the Fragment could contain more than just one child. Or is this API confusing and we should just recommend people needing this pass in a Fragment as the child of the Reparent?
When a Reparent's tree is detached from the DOM (the DOM nodes are not part of the document, but the tree still exists so it can be re-inserted later) and the Reparent is given new children. Should it render those children into the detached tree; or, should it just store the new children and wait until the tree is re-mounted before rendering them.
I can see rationales for both:

If we render to a detached tree it should mostly work out, but some dom operations that may be done in refs may not like it and expect there to be a parent. Perhaps something like .closest that tries to crawl up to the root or dom operations that calculate layout.
If we don't render to a detached tree then React components inside that tree will not be updated. If this includes a props change that affects something like Redux/Flux subscriptions the Component may continue to work with out of date subscriptions, which could result in runtime errors as the Component tries to access data that doesn't exist anymore or is under a different name now.

I've added a possible alternative to .unmount(), a .keep() signal.
I'd like some feedback on that idea. If people like it I may refactor the RFC to use .keep() and make .unmount() the alternative.
I've also clarified the goals and explained why reparenting is useful even if we can't retain native state like focus and iframe contents and even when on React Native where there's not necessarily any concept of reparenting at the native View level.

I like the idea of moving nodes around, but this seems as a needless overhead for the developer. Why not introduce new react-specific attribute, such as is the key that will tell React that this is the same node?

I like the idea of moving nodes around, but this seems as a needless overhead for the developer. Why not introduce new react-specific attribute, similar to the key that will tell React that this is the same node?

This is mostly explained in the Requirements section. Here are a few points:

No other React API has the concept of a globally unique string.
Using globally unique keys makes using reparents harder in libraries since you have to ensure that your keys will not conflict with any the user makes.
Using globally unique keys makes it harder to use things like database IDs for the unique key. You can guarantee that this ID is unique within the set of data you want to be able to move around, but you cannot guarantee that the ID is 100% unique among all possible reparentable nodes. Thus you have to pad it with uniqueness that shouldn't be necessary for the type of reparenting you are doing.
If we use keys it is not possible to hold on to detached nodes. There are legitimate reasons to want to be able to intentionally detach a tree temporarily. And there are legitimate cases where a tree momentarily may not be present in the tree during a move but you do not want it to be unmounted (and this type of async move may become more common after the future async rendering mode is introduced).

I'm currently building a web browser-like app in react native. One of the requirements is to be able to switch from viewing a single tab to viewing all tabs in an animated scroller - at the moment, due to the inability re-parent, switching between views causes tabs to be re-mounted from scratch, loosing any and all state. So re-parenting would be useful for me.

I would love this feature as well, when doing a responsive app. I cannot understand why they did not have this from the very beginning, it is brilliant!

Great work on the RFC @dantman. 🙌 That'd definitely be useful for us at @PSPDFKit as well!
The .keep API makes sense as it must be possible to retain elements even if they aren’t rendered it in the current tree. However it seems a bit counter-intuitive that the reperantable element will also be kept in the following example:
class DetachableTree extends Component {
  reparent = React.createReparent(this);

  render() {
    const content = this.reparent(this.props.children);
    return this.props.show && content;
  }
}

I think it's also against the design principles of React that the render method has side effects. In this case, the render method might return null but we still have to track that we want to keep the reperantable - thus we would need to save that information as a side effect. Maybe this can be improved by rendering a special component that describes this keeping state?
Another problem is that the lack of a context makes it possible to create a reparent deep in the tree and pass it upwards to render it in the root. That's something that's not possible with the context API for example and I'm not sure if this causes any implications.
I also fear that the id passing might be very confusing for developers that use it. Your examples make use of getDerivedStateFromProps twice which smells because that method should rarely be used at all. I personally prefer your createReparentContext to solve this. In this API, you create a context/repereantable pair similar to the new context API. This will drastically reduce the chance of an id clash since you are in total control of the context. Third party APIs can never clash with your repereantable contexts as well.
Here’s one idea that I have in mind that tries to cope with the problems I outlined above. I decided to migrate your TemplateWidget example to show you how you can get rid of gDSFP:

TemplateWidget using createReparentContext
const WidgetReparentContext = React.createReparentContext();

function TemplateWidget({ id }) {
  return (
    <WidgetReparentContext.Reparentable id={id}>

Hello from widget {id}

    </WidgetReparentContext.Reparentable>
  );
}

function Section({ title, widgets }) {
  return (

{title}

      {widgets.map(widget => <TemplateWidget {...widget} key={widget.id} />)}

  );
}

function Template({ sections }) {
  return (
    <WidgetReparentContext.Provider>
      {sections.map(section => {

;
      })}

      {keep}
    </WidgetReparentContext.Provider>
  );
}

Nothing special about this so far, this is basically your createReparentContext idea. One thing to notice here is that your solution does also keep widgets mounted that were once passed in as props but are no longer. I think that this use case can be further generalized into custom cache strategies which must know which items are added in order to know how to cache them.
To solve this, I assume that we could add a callback to the ReparentContext.Provider which gets called whenever a reparentable key is rendered. A regular React component could then collect all of those and render special "keep" placeholders so that they are always part of the render results:

TemplateWidget using createReparentContext with onReparentableRendered
const WidgetReparentContext = React.createReparentContext();

function TemplateWidget({ id }) {
  return (
    <WidgetReparentContext.Reparentable id={id}>

Hello from widget {id}

    </WidgetReparentContext.Reparentable>
  );
}

function Section({ title, widgets }) {
  return (

{title}

      {widgets.map(widget => <TemplateWidget {...widget} key={widget.id} />)}

  );
}

class Template extends React.Component {
  state = { keptReparentables: [] };

  // In this example we use the `onReparentableRendered` callback to be notified
  // whenever a new reparentable is rendered. This will easily allow more
  // advanced caching systems (e.g timeout- or LRU-based) to be implemented
  // as React components.
  addReparentable = ({ id }) => {
    this.setState(state => {
      // We already cache this reparentable so there's nothing to do.
      if (state.keptReparentables.includes(id)) {
        return null;
      }
      // We add this to our kept reparentable list.
      return { keptReparentables: [...state.keptReparentables, id] };
    });
  };

  render() {
    const { sections } = this.props;
    const { keptReparentables } = this.state;

    return (
      <WidgetReparentContext.Provider
        onReparentableRendered={this.addReparentable}
      >
        {sections.map(section =>
)}

        {/* A special kept flag will tell React to keep this reparentable around
            if it exists without updating properties. */}
        {keptReparentables.map(id => (
          <WidgetReparentContext.Reparentable id={id} keep />
        ))}
      </WidgetReparentContext.Provider>
    );
  }
}

I'd love to hear your thoughts on this API 😊 I also think that this API can be implemented in userland if we have https://github.com/facebook/react/issues/13044 (well, for ReactDOM only at least as long as createPortal is DOM-only).

I think it's also against the design principles of React that the render method has side effects. In this case, the render method might return null but we still have to track that we want to keep the reperantable - thus we would need to save that information as a side effect. Maybe this can be improved by rendering a special component that describes this keeping state?

This is correct, we do have to accept that in this case not only is there an effect from a return from render but also a .keep()/Reparent() in render. I am half on/half off with this idea though, while technically true it being a side effect, in a way we are just tracking references in render() and GCing things when references disappear which doesn't feel as strange as other types of side effect. I did consider requiring that this be passed to .keep() if it turned out this behaviour couldn't be implemented in React.
Fragments do make it possible to, use some sort of internal reference tracking element where we pass the reparent to it to keep the reference without it being rendered, without it messing with the dom. But I'm very hesitant to use that pattern given how horrible it looks to use that type of pattern. How it limits how render() can be written, in some cases forcing you to rewrite what could be a conditional if (...) { return ...; } into an if (...) { result = ...; } return <>{/* code to keep references to reparents */}{result}<>;. And I also feel a little awkward about how .keep() is designed to allow you to keep a reference to something while still rendering it somewhere else, something that feels at odds with rendering a special component because you are returning a reparent in 2 places in JSX, it just happens that one of those places is actually a special type of component that doesn't actually render the reparent using a loophole to bypass the "a reparent may only be rendered in one place" rule.

Another problem is that the lack of a context makes it possible to create a reparent deep in the tree and pass it upwards to render it in the root. That's something that's not possible with the context API for example and I'm not sure if this causes any implications.

I suppose someone ingenious might be able to find a way to pass a reparent upwards and find a way to use a few tricks to make a reparent render the component that first created the reparent as as child. Although I don't believe this is possible without the use of a second reparent that technically means the component wouldn't actually be a child of the reparent created in the component.
I'm also not sure this is even a problem, as with the new .keep() API I believe a Reparent is now pretty much disconnected from the component that creates it. We only opt-in to patterns like that because it's useful to have a component keep references to a series of reparents so they don't unmount and pass those reparents to its children.
Also worth noting, it's not directly within the React tree but the Portal API does allow you to render something in the root from a child component of the root.

I also fear that the id passing might be very confusing for developers that use it. Your examples make use of getDerivedStateFromProps twice which smells because that method should rarely be used at all. I personally prefer your createReparentContext to solve this. In this API, you create a context/repereantable pair similar to the new context API. This will drastically reduce the chance of an id clash since you are in total control of the context. Third party APIs can never clash with your repereantable contexts as well.

The IDs are purely an implementation detail of the example, they aren't required of the API. If someone wants they are free to use a Map and object keys in theirs. Id clashes are also a non-issue, the IDs only matter within the scope of the context created by the user in the example. i.e. You can create another context containing reparents for something else and use the same ids, there will be no clash because they are separate contexts – the IDs do not need to be globally unique.
Honestly the only reason that example is ID based is because the application I am currently working on happens to use IDs. I needed an example of that kind of pattern of passing a dynamic set of reparents to descendents via context, so I just used what I had on hand. That example is basically just a pattern I'm actually using in the application I'm currently working on right now, just stripped down to the most basic/generic parts so I'm not sharing any client code.
Also I think the examples originally needed getDerivedStateFromProps a bit more in the pre-keep version of the rfc. Now that we have keep, I have a feeling that you could probably refactor that example to work using very very minor memoization in render(). Also that example is an example of one of the most extreme most advanced ways you can use a reparent, the example kind of is the "rare" situation where you do want gDSFP.
Speaking of userland things, I am aiming for an api that is as flexible and supporting of advanced cases as possible. As I expect that a simple API will not cover all the use cases people want. And if we implement an API that is advanced/flexible enough people will be free to write libraries that expose simple APIs for using reparents. This will let different use cases for reparents be supported by separate libraries that each have an API that is simplest to use for the use case they target. And will allow anyone with a use case too advanced for a library to handle to use the built in API.

However I'm still not keen on the idea that we're sacrificing the purity of the render method because we have to track keep() calls. I agree that your API looks more compact but would it make it clear that, for example, you'd have to call setState() and force a re-render to be able to "unkeep" reparentables? I think a React component would make that more obvious because people using React are already familiar with that concept.

Is this really something that strange?

You are explicitly calling a method that says it will keep a reference to the reparent. And in some cases you are explicitly calling a .keep() method, whose sole purpose is to keep a reference and only reason you'd call it is if you knew what it did.
I'm also not sure forcing a re-render with setState is that strange either. If you keep/render children for a reparent in a render you've essentially "used" the reparent in a render(), it doesn't seem that strange that something you used in a render() won't go away until that component is rendered again.

That can easily be solved by returning three elements from the createReparentContext() API and not calling the special loophole reparentable at all:

Ok that covers the strangeness with a different API. Though I don't really like this id based pattern because there are also use cases for singular reparents.

Another thing that is impossible with your API (which I just found out now that I sketched the above example): It would require the use of a class component for the this to be passed into createReparent().

Oh, whoops. I didn't realize that my examples and my protocol still listed this/Component in them. Ignore those, the rewrite to use .keep() was so big I missed things. this was required in the original .unmount() based API because we needed an "owner" so we could implicitly unmount when the owner unmounted. With the .keep() we do not need to know the owner because we only have to keep track of what components are using the reparent in order to know when to umount its contents.
Every time an example uses React.createReparent(this) it should actually be React.createReparent() now.

Another example where the .keep() API is insufficient is when you think about unit testing using techniques like the shallow renderer. How would you write an assertion that verifies that .keep() is called indeed?

It's possible you may need a bit more than a shallow render, I'm not sure how shallow the shallow renderer is. But you can test the effects of keep by watching whether a component instance unmounts or not. I think this is justified because you are not testing the react tree but testing the effects of a mounting behaviour.
Something along the lines of:
let mounted = false;
class Foo extends Component {
	componentDidMount() {
		mounted = true;
	}

	componentWillUnmount() {
		mounted = false;
	}
}

const reparent = React.createReparent();
function Bar({show, children}) {
	reparent.keep();
	return show ? reparent(children) : null;
}

renderer.render(<Bar show><Foo /></Bar>);
// wait
expect(mounted).toBe(true, 'Foo should be mounted when rendered through a reparent');

renderer.render(<Bar hide><Foo /></Bar>);
// wait
expect(mounted).toBe(true, 'Foo should not unmount even when not rendered, becase .keep() was called');

renderer.render(<Bar show></Bar>);
// wait
expect(mounted).toBe(false, "Foo should unmount when it is no longer part of the reparent's children");

+1 to not particularly liking the id based approach. I find it confusing.
If the side-effect keep-function is seen as a problem, would making keep into a React Component be an acceptable alternative? I think this has been partially in discussion between you already, but I wasn't exactly sure if it was the same as I was thinking about.
So essentially something like a React.Fragment, but instead of allowing a grouped-together set it would act as the keep-call for one or more Reparents inside it. This admittedly adds complexity to the already relatively complex API but would remove the side-effects and would make the API a reasonably accurate rendition of the actual resulting DOM: The main DOM tree expands as the React tree does, while the Reparent components inside the Keep component are still in existence in the DOM, just in a detached state. The component could even be named with something to that effect, like Detached or I don't know.
Sorry if this is just rehashing the same ideas already given and shot down.

@aapoalas No need to feel stupid, thank you for helping us out here 🙌
So just to clarify, you have something like this in mind, right?
const reparent = React.createReparent();

function SomeComponent() {
  return (
    <React.Fragment>
	  {reparent(
Some DOM
)}

      <React.Detached>
        {reparent()}
      </React.Detached>
    </React.Fragment>
  );
}

I think one problem here is the same that @dantman pointed out earlier: It's hard to see why we're not allowed to render the same reparent() twice inside the React tree but it's ok when one of them is wrapped inside a <React.Detached>. I'm quoting here because I found his words clearer:

And I also feel a little awkward about how .keep() is designed to allow you to keep a reference to something while still rendering it somewhere else, something that feels at odds with rendering a special component because you are returning a reparent in 2 places in JSX, it just happens that one of those places is actually a special type of component that doesn't actually render the reparent using a loophole to bypass the "a reparent may only be rendered in one place" rule.

What I like about this idea though is that the return value of createReparent() can now easily be a component itself which makes it a mot more intuitive to use:
const Reparent = React.createReparent();

function SomeComponent() {
  return (
    <React.Fragment>
	  <Reparent>
Some DOM
<Reparent />

      <React.Detached>
        <Reparent />
      </React.Detached>
    </React.Fragment>
  );
}

What I like about this idea though is that the return value of createReparent() can now easily be a component itself which makes it a mot more intuitive to use:

That's an interesting idea, one caveat though. How do we differentiate between rendering <Reparent /> as a "keep" and rendering <Reparent></Reparent> with empty children? We do need to allow a reparent to be rendered with empty children. It would be really confusing if the answer to that was "<Reparent /> behaves differently when it is a child of <React.Detached />.
I still don't quite like the idea of an element based API for reparents. But this could work for one:
const Reparent = React.createReparent();

function SomeComponent() {
  return (
    <React.Fragment>
      <Reparent.Reference />

      <Reparent>
Some DOM
</Reparent>
    </React.Fragment>
  );
}

We can use a different name than .Reference if someone can come up with one. But this would also make <React.Detached /> unnecessary. Rendering the Reparent itself would render it and its contents. But rendering the <Reparent.Reference /> would just be a reference to the reparent and wouldn't change it's contents.
Though I still do not like the idea that a complex branching render() would have to be refactored so it can return elements that aren't actually elements and aren't actually rendered in order to keep references to something.

What if you could pass a component to createReparent:
const reparent = React.createReparent(() =>
Some DOM
)

function SomeComponent() {
  return (
    <React.Fragment>
      <Reparent />
    </React.Fragment>
  )
}

@j-f1 Can you elaborate what the benefits of this approach is over using the regular React tree in the render() function as proposed? I do think it makes it harder for example to swap the contents.

@philipp-spiess What I was thinking is that if you stopped rendering the <Reparent />, it would cache the rendered node somewhere to reuse when you rendered it again.

@philipp-spiess I was thinking something along the following lines (though thinking deeply on this I keep finding more and more problems so this isn't going to be a whole lot of good I think):
I would have createReparent return a unique React Element that acts similarly to a React Fragment; inside it you can render any Components and the contents is diffed normally for changes. Each time you render it, the contents must be rendered as well, no keeping of references that remember what the previous contents was and would nicely render that stuff for you or some such.
The React.Detached Component would again be similar to React Fragment; inside it you can render any Components and the contents is diffed normally for changes. Yes, I mean you could also render normal divs etc. inside this component. It would act the same as creating a DOM tree manually without appending it to be a child of the body. This would, however, be mostly useless without the Reparent Component, as the moment you "move" your normal DOM elements from within the React.Detached to some actual DOM tree, the Components of course unmount and are destroyed, and new ones created in the new location. The Reparent Component could however use the React.Detched to keep itself alive while detached without ill effects.
So the usage of these would be something like:
const ReparentA = React.createReparent(); // This would more likely be created inside some parent component during mounting or updating based on some inflowing data

class MyPointOfForking extends React.Component {
  render() {
    const {
      children,
      condition,
    } = this.props;
    return (
      <ForkA>
        {condition === true && <ReparentA>{children}</ReparentA>}
      </ForkA>
      <ForkB content={condition === false && <ReparentA>{children}</ReparentA>} />
      <React.Detached>
        {typeof condition !== "boolean" && <ReparentA>{children}</ReparentA>}
      <React.Detached>
    );

So we have some React tree (children in this case, but could just as well be created inside the render function) that we want to render somewhere, but the location changes based on some condition, or it can be detached from the DOM entirely in some cases.
Thus we have two choices by and large: Either we place the ReparentA Component (remember, this is a unique individual) in a normal React DOM tree one way or another (ForkA and ForkB, where ForkA will render directly as children, while ForkB might likely pass the content prop onwards to somewhere even deeper, before it finally gets rendered as a child), OR we can render the component in a detached React DOM tree.
Doing more than two of these will cause an error. You cannot render a Reparent in two places, not even if one of those is a Detached DOM tree.
I can see some problems with this approach though:

Keeping the Reparents straight (which one should render what content etc) can easily become a chore and might well end up detaching and remounting your contents even thought the whole point is to avoid that.
Having a unique Component is heretofore unknown in React and will indubitably cause confusion.
The need to keep the contents / children of each Reparent in order will likely lead to passing of the Reparent Components as props or children through React Component trees, and much deeper than is done currently. This is not necessarily a good thing, though both the Context API and Portals can be of help here.

Some good things:

The lifecycle of a Reparent component is essentially identical to that of a normal component; if at some point the component fails to be returned from some render function, it will unmount.
Although it may seem so, this approach does not mind rendering the pretty much anywhere; even though the Reparents are likely created within some parent component, f.ex. based on an array of ids, the parent component does not tie its own lifecycle methods to the Reparents. This should work fine as long as you do not attempt to render a Reparent as a parent of the component that originally created the Reparent, as that would lead to a constant creation of a new Reparent that would then become its own parent, triggering a new creation...
A Reparent that can be rendered at present DOM node or in some deep child can quite easily be made using the Reparent and Context API. Use Context to pass on either null or the Reparent component, while rendering the other at present node.
A Reparent that can be rendered at present DOM node or in eg. a modal container can quite easily be made using the Reparent and Portal API. Render the Reparent component either normally, or into your modal container using a Portal.
A Reparent that can be detached from the DOM at will is as easy as the above Portal case. Just use React.Detached instead of React.Portal (which React.Detached is just a special case of, essentially, and could easily be created in userland)

Doing more than two of these will cause an error. You cannot render a Reparent in two places, not even if one of those is a Detached DOM tree.

The ability to "keep" a reference while still rendering it elsewhere is a requirement. This API won't work well when you have to wait for something async to finish when moving a reparent from one child to another.

I don't quite understand what kind of reference do you want to keep, and what would you want to do with it.
Also, what do you mean by "wait[ing] for something async to finish when moving a reparent from one child to another"? Do you mean that part of the content of a reparent will move first, and some other part will be moved later once some async action has finished?

By keep a reference I mean it should be possible for a component to use a reparent such that it will not unmount, without providing children, and while still allowing another component to actually render the reparent.
By waiting for async, I'm referring to a scenario where a parent with dynamic contents passes reparents to children (likely using context), the children render the reparents, then the dynamic content changes. If the dynamic content changes such that a reparent immediately moves from one child to another child then the reparent would normally move fine. However, if the second child happens to need to wait for say some API call to fetch before it can render then the reparent will not have a destination until that is fulfilled. If the parent cannot essentially say "this reparent is still in use, even if no-one is currently rendering it" then while we are waiting for the API call to finish the reparent will end up unmounting instead of detaching so it can be inserted into the second child when it renders.

Reference: What does the first component "use" the reparent for if it does not provide content for the reparent, and does not render the reparent?
Waiting for async: In my opinion this is simply a question of keeping proper tabs on the reparent components, just as you would keep proper tabs on components you create in normal renderers. eg. The second child needs to wait for some API call before it is ready to actually render the reparent. Then in its renderer it should return <React.Detached>{reparent}</React.Detached> until the API call is done, after which it will render some other stuff along with the reparent. Or alternatively the parent should keep tabs (via Redux store, or just callback functions, or w/e) on which reparent components are actually in use, and itself return the rest inside a React.Detached Component.
If it really is thought necessary to allow for the parent to essentially call keep() on reparents it has created just "to be sure they don't disappear", then I believe we need to bring back the this-binding and maybe even explicit unmounts (I've reversed my stance on .keep()-function inside render :)).

There will still be problems with Async React. In the future, React might render and commit one part of the tree before the other part renders (see this tweet from Dan). This means that there might be a "hole" when no reparent is rendered although you're immediately moving it into a different subtree.
This is why we need an API where a shared controller can tell React to not GC certain reparents - No matter if they appear in a commit phase or not.

Reference: What does the first component "use" the reparent for if it does not provide content for the reparent, and does not render the reparent?

The parent knows that the item the reparent is associated with still exists. It does not know if it will be rendered.

Waiting for async: In my opinion this is simply a question of keeping proper tabs on the reparent components, just as you would keep proper tabs on components you create in normal renderers. eg. The second child needs to wait for some API call before it is ready to actually render the reparent. Then in its renderer it should return <React.Detached>{reparent}</React.Detached> until the API call is done, after which it will render some other stuff along with the reparent. Or alternatively the parent should keep tabs (via Redux store, or just callback functions, or w/e) on which reparent components are actually in use, and itself return the rest inside a React.Detached Component.

Assuming the parent knows enough about the async request, this just adds needless complexity trying to track this when there is no need to track it
The child returning a detached container works if the child is the one doing the network request, but if the async request comes from an intermediate component "Parent > AsyncElement > Child" neither of them know when they should render a detached node in order to just avoid the component being unmounted.

I've reversed my stance on .keep()-function inside render :)

How about the alternative JSX based api? That uses a <Reparent.Reference />.

There will still be problems with Async React. In the future, React might render and commit one part of the tree before the other part renders (see this tweet from Dan). This means that there might be a "hole" when no reparent is rendered although you're immediately moving it into a different subtree.

I do not know much anything about Async React, having already forgotten all that was said in the presentation. I believe this is not an abyss we should look too deeply into. Dan mentions avoidance of "tearing" and if reparents were a current part of React, I'm sure reparents losing state / unmounting would be considered "tearing". He also makes a vague reference to the postponing of commission being an opt-in thing, so such a situation where a reparent gets unmounted due to postponed rendering could also be argued to be a user error.

The child returning a detached container works if the child is the one doing the network request, but if the async request comes from an intermediate component "Parent > AsyncElement > Child" neither of them know when they should render a detached node in order to just avoid the component being unmounted.

Mmm... I'd want to say that the AsyncElement here should take the reparent from the context and either render it in React.Detached, or pass it as a prop to Child once it is done with the necessary request. Similar to lifting of state and all that. Of course, if AsyncElement here is some 3rd party component that you can't mess around with, you may be in quite some trouble.

How about the alternative JSX based api? That uses a <Reparent.Reference />.

... It's okay, maybe. I'm not exactly thrilled with it, as I already managed to sell myself on my idea. (Surprise!) I've managed to convince myself that a  as close to a normal element as possible is the prettiest and most elegant solution and thus the best. So having this extra Reference thing is weird as it doesn't really have any precedent and smells a bit of laziness ("I don't know if my stuff is actually needed, so I'll just keep it around just to be safe...").
The whole Reference / keep() -system feels a little like tying the <Reparent> into the parent's lifecycle methods without actually doing it. So in that sense if what is wanted is a type of reparent that is created and stays in existence until it is explicitly thrown away (leaving out the Reference is an explicit act), then I'd maybe rather just have <Reparent> automatically become detached and stop updating if it is not rendered anywhere, and bring back the explicit unmount(). This would remove the need for React.Detached and Reference and would still allow reparents to be relatively normal components.
Throwback:

We do need to allow a reparent to be rendered with empty children.

Why? What would an empty reparent accomplish? Except work as a different kind of null. How I see it in my proposal, once a reparent is created it can be used, become unmounted and be reused later if that is wanted, for some reason or another. Of course all components inside it would likewise be gone, but that's a designed for and intended facet of my proposal.
Rendering the reparent as empty would, of course, work as well but it would simply not do anything nor would it be a necessary thing in order to keep the reparent usable for a future case. I can only see this being a reasonable situation when the only child (or all children) of a reparent return nulls from their renderers, in which case the reparent is empty, DOM-wise, but not React-wise.

I do not know much anything about Async React, having already forgotten all that was said in the presentation. I believe this is not an abyss we should look too deeply into. Dan mentions avoidance of "tearing" and if reparents were a current part of React, I'm sure reparents losing state / unmounting would be considered "tearing". He also makes a vague reference to the postponing of commission being an opt-in thing, so such a situation where a reparent gets unmounted due to postponed rendering could also be argued to be a user error.

From what I've seen of the suspense api so far. It's encapsulated enough that forcing a parent to know enough about what it's children are rendering in order to know when it needs to render a detached node in some apps would break encapsulation. And a reparent unmounting because a placeholder was rendered temporarily is not user error.
Additionally while suspense is great, it's not the only way to do async react. Apps are currently already doing async react using componentDidMount and state. Even if suspense were to somehow solve the reparent issue internally and avoid unmounting something that may be used in the tree it is waiting for; it still wouldn't solve the issue for all the apps currently not using suspense for fetching data.

Mmm... I'd want to say that the AsyncElement here should take the reparent from the context and either render it in React.Detached, or pass it as a prop to Child once it is done with the necessary request. Similar to lifting of state and all that. Of course, if AsyncElement here is some 3rd party component that you can't mess around with, you may be in quite some trouble.

Even if we assume AsyncElement wasn't a 3rd party component, pretend it was say a lightweight component tasked with downloading i18n data and then rendering its children once that data is available. It would be a pretty big encapsulation break to say that knowledge of Child's reparent should be hoisted into AsyncElement.
And frankly even the fix of having the Parent pass a "render this if you aren't going to render Child at the moment" down through the tree gets pretty messy as you try to add layers.

Why? What would an empty reparent accomplish? Except work as a different kind of null. How I see it in my proposal, once a reparent is created it can be used, become unmounted and be reused later if that is wanted, for some reason or another. Of course all components inside it would likewise be gone, but that's a designed for and intended facet of my proposal.

My issue was primarily with the distinction between <Reparent>Foo</Reparent> being the way that one renders to a reparent. And <Reparent></Reparent> ending up being a reference that keeps the children and should usually be used in <React.Detached>.
A) React allows you to render an element with no children, and the only difference is the absence of the data in the children prop. It would be a pretty large break from React conventions if at a fundamental level <Reparent>Foo</Reparent> rendered 'Foo' and <Reparent></Reparent> kept rendering 'Foo' instead of removing it.
B) children can also be undefined as a result of a conditional, <Reparent>{condition && <Bar />}</Reparent>. You would expect this to render <Bar /> when condition is true <Foo condition /> and nothing when condition is undefined (remember <Foo /> has an undefined condition, not false). Surprise! It actually renders <Foo /> when true, and when undefined it's actually a reference which would suggest that the reparent is still rendered but its children are not modified.

The whole Reference / keep() -system feels a little like tying the  into the parent's lifecycle methods without actually doing it. So in that sense if what is wanted is a type of reparent that is created and stays in existence until it is explicitly thrown away (leaving out the Reference is an explicit act), then I'd maybe rather just have  automatically become detached and stop updating if it is not rendered anywhere, and bring back the explicit unmount(). This would remove the need for React.Detached and Reference and would still allow reparents to be relatively normal components.

It actually feels like the reverse for me. I think of it similar to GCing. React doesn't unmount things as an explicit order from someone to unmount something, it unmounts things implicitly when they are no longer in use anywhere. Just like how a GC tracks what objects are being used and removes any objects that are no longer referenced.
Having to explicitly track and .unmount() reparents sounds like adding an imperative order, in a place where React doesn't work imperatively. While .keep() and <Reparent.Reference /> are declarative "I'm still using this" declarations. And they fit in with the GC-like behaviour of unmounting by declaring when you are still using something (have a "reference" to it like the GC tracks references) and letting React unmount it when you no longer indicate it is in use.
Aside from that, people brought up some legitimate concerns about the explicit .unmount() API in that it's too easy to accidentally introduce a memory leak.

... It's okay, maybe. I'm not exactly thrilled with it, as I already managed to sell myself on my idea. (Surprise!) I've managed to convince myself that a as close to a normal element as possible is the prettiest and most elegant solution and thus the best. So having this extra Reference thing is weird as it doesn't really have any precedent and smells a bit of laziness ("I don't know if my stuff is actually needed, so I'll just keep it around just to be safe...").

I was going to agree and arguer further that the idea of a unique instance <Reparent> element where Reparent is a dynamically generated element with it's own context was strange and didn't behave like a normal element any more than adding .Reference. But then I realized I was wrong. Uniquely generated elements and use of Foo.Bar is not strange or without precedent.
const FooContext = React.createContext();
// ...
<FooContext.Provider value='foo'>
  <FooContext.Consumer>
    {foo => {foo}}
  </FooContext.Consumer>
</FooContext.Provider>

React's new context system's Provider and Consumer are unique component instances where the component itself is tied to the context of the FooContext. And they also are commonly used in the Foo.Bar format.
The only modification I need to make to my suggested API to make it behave exactly like the context API is to make it so that you don't use Reparent directly as an element.
const Reparent = React.createReparent();
// Keep a reference to the reparent, without changing its contents.
// Can be used as many times as you want.
<Reparent.Reference />
// Render something into the reparent's context
// and render the reparent into an element.
// Can only be rendered in one location at a time.
<Reparent.Scope>...</Reparent.Scope>
// Render a reparent into a detached state.
// This is distinct from just using `<Reparent.Reference />` to keep a reference
// to avoid the component unmounting and it detaching when it's no longer rendered.
// The distinction is that in this case you are explicitly updating the
// reparent's contents while it is detached.
<React.Detached>
  <Reparent.Scope>...</Reparent.Scope>
</React.Detached>

All three of these terms are up for better naming suggestions.

The only modification I need to make to my suggested API to make it behave exactly like the context API is to make it so that you don't use Reparent directly as an element.

Yes, this is good! Although I'd at least give thought to <Reparent.Reference> having to encapsulate the React tree within which <Reparent.Scope> will be used like how it works with Context API. This might end up with a distinctly weird, deep tree of <Reparent.Reference>s when an array of reparentable components are created, but would allow for control over where the Reparent might actually be returned from.
Overall, though, I think this might well be the True Form of the API 👍
Sidenote: I can't remember too well how <Placeholder> was meant to work and if it would break this idea, but I was imagining a reparent unmounting tied to "synchronized" render states; that is to say that if a reparent component was removed from the React tree and did not appear elsewhere, then the unmounting of said reparent would be delayed until the next complete, "unteared" render state is reached. This would cause delayed componentWillUnmount calls from reparents in Async React applications but would otherwise be semi-ok. However, this does not offer any way for non-Suspense components to handle Reparents "natively".

Although I'd at least give thought to <Reparent.Reference> having to encapsulate the React tree within which <Reparent.Scope> will be used like how it works with Context API.

Interesting idea. But no good, that would result in this.
const ReparentA = React.createReparent();
const ReparentB = React.createReparent();
const ReparentC = React.createReparent();

<ReparentC.Reference>
	<ReparentB.Reference>
		<ReparentA.Reference>
			<Foo />
		</ReparentA.Reference>
	</ReparentB.Reference>
</ReparentC.Reference>

Doing this dynamically would be a mess. If your dynamic structure uses a list of dozens of children, then the DevTools tree would be dozens of elements deep for everything. And ironically, unless you make use of an additional <HostReparent.Scope> the entire tree outside the reparents will remount every single time you add/remove a reparent. 😱🤣

that would result in this

Yeah, I foresaw this. It would be so nice to look exactly like the Context API but it definitely is better without doing so.

Sorry for throwing in the confusion about async React. I thought more about it and this is an implementation detail and not a point for deciding about the API.
👍 for the latest JSX API - I guess the <React.Detached/> component is only for demonstration purposes and not part of this RFC though, correct?
Here are some alternative name ideas for the <Reparent.Reference /> component:

<Reparent.Keep />
<Reparent.KeepAlive />
<Reparent.Persist />
<Reparent.KeepLatest />
<Reparent.NoUnmount />

And here are some ideas for <Reparent.Scope/>:

<Reparent.Target />
<Reparent.Content />
<Reparent.Inside />
<Reparent.Reparentable /> 🙃

My favorites so far are <Reparent.Persist /> and <Reparent.Content /> but I urge you to just take this as additional input with no strings attached as I'm terrible at finding good names and always go for the "make it easy to grep and change later" solution 🙈

👍 for the latest JSX API - I guess the <React.Detached/> component is only for demonstration purposes and not part of this RFC though, correct?

React.Detached would be included since I brought up the use case of rendering a reparent's children while it is detached. And this functionality is useful in non-dom scenarios as well so it makes sense for Detached to not be a ReactDOM/custom thing.

@dantman What do you think about replacing this PR with a newer one that incorporates all the issues discussed? I think this will make the RFC much more approachable since the discussion here is already very long. I remember it took me quite some time to read through all that and we've since doubled the comments 😐
Let me know if I can help you somehow!

Sorry for being that person, I have not read all of the comments. However I wanted to include a usecaes:
I have a React component that I need to transition from a list of posts that is animating, into a React portal which is outside of the  to avoid position: absolute and transform issues, then it will transform the location to a new spot in the page (the top full width) and re-attach itself to the react dom again.
Basically I'm trying to make the image transition effect you get in allot of IOS/Android apps.

Does this RFC suggest that React would move around the actual DOM nodes? Is it technically possible? For example, if one of the child node was a playing <video> element, by removing it from DOM and reinserting into a different parent, would it still be playing?

IMO it should just move the element and leave the developer to do whatever they would do. For what it's worth, the behavior on moving a video element is clearly defined in the HTML spec (https://html.spec.whatwg.org/multipage/media.html#media-playback):

When a media element is removed from a Document, the user agent must run the following steps:

Await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with ⌛.)

⌛ If the media element is in a document, return.

⌛ Run the internal pause steps for the media element.

Note that the element is only paused if it was completely removed from the DOM (i.e. not moved). However in my tests in Firefox and Chrome I found that Firefox follows the spec (continues playing the video) while Chrome violates the spec (pauses regardless of the destination of the element). Nothing is mentioned about currentTime.
I'm filing a bug report for Chromium about this: https://bugs.chromium.org/p/chromium/issues/detail?id=910988
So the summarize:
According to the spec, video should continue uninterrupted when moved around the DOM, but at worst, you might need to call .play() again. This is a compelling use case to support re-parenting in React.

😆Coming back to this years later, I'm surprised that my proposed API still holds up. I thought I might need to revise it to work with hooks. But it looks like the proposal still works for functional components with hooks. Only perhaps with a user land helper for creating a singular reparent within a component.
It's hard to sift through the comments and figure out what revisions I accepted. But I am thinking of reversing some of the ones I might have accepted.
There was a lot of discussion about a JSX style API. It seems I accepted and got into this idea because of the similarity to the context render props API. However now that Context.Consumer has become something rarely used, with useContext(Context) being more common I'm rethinking it. The "declarative magic" of tracking renders where .keep() is used is no longer strange now that hooks do effectively that.
I'll need to sleep on some idea of what a reparenting API that fits in with hooks would look like.

This might be a stupid question (I'm not familiar with the inner workings of React), but couldn't reparenting be solved by introducing a globalKey attribute (akin to the key attribute), which must be unique across all components in the component tree? Then upon re-rendering, React would compare the global keys of the previous tree to the global keys of the new tree, and if any keys have "changed locations" in the tree, move the DOM nodes accordingly (as well as internal references to the components).

This might be a stupid question (I'm not familiar with the inner workings of React), but couldn't reparenting be solved by introducing a globalKey attribute (akin to the key attribute), which must be unique across all components in the component tree? Then upon re-rendering, React would compare the global keys of the previous tree to the global keys of the new tree, and if any keys have "changed locations" in the tree, move the DOM nodes accordingly (as well as internal references to the components).

So, there is a lot to unpack here. As requested in #182, I'm making a pass to review the things that I've been hesitant to review because a proper review would take a very long time to write. So I'll instead leave some cursory comments.
Reparenting is one of the Hard Problems(tm). It basically affects all features at the same time. So the bar for a proposal would have to be extremely high. I think over time we've come to realize that "true reparenting" in all senses of the word usually isn't really needed, and can be a distraction. Here's a few concrete scenarios, and what we tend to use instead:

"Detachable video player". That seems like a canonical use case for reparenting. E.g. you start watching a video inside a tweet, then you scroll down but the video detaches and keeps playing. Intuitively this seems like a case for reparenting. However, it's not quite clear-cut if you think about what should happen to Context. I think you probably want the Context from the place where the video was detached. Not from the top level where it got reparented to. You might also want to keep receiving prop updates from the original place in the feed, e.g. if the like count changes. I know people like to say "UIs are graphs, not trees" but I really don't know that this is actually true. Anyway, for cases like this, it seems like the desired effect is visual reparenting / DOM reparenting while the React tree is intact, and the component stays in its original place. This is clumsy but already possible today. The way you do this is by combining refs and portals. The "tweet" (original parent) uses a ref to a DOM node, and places another DOM node into it. It portals the "video" (the child) into that second DOM node. Then, you can imperatively move that second DOM node anywhere in the DOM tree when needed, including reattaching it back. The effect is purely visual, and the actual data flow (and the React tree) stays the same, so there are no difficult questions to resolve.
"Route transitions". There are actually two different cases.

"Compatible transitions". The example in https://github.com/reactjs/rfcs/pull/34#issuecomment-678592702 mentions page layout. But that already works in React, in general. It only doesn't work if your framework forces you to declare route pages as Home, About, etc, which use Layout inside. But a more React-y way should rely on reconciliation directly. I think this says that routes shouldn't exactly be components, since we really want the Home page and the About page to be able to "line up" because they contain a Layout. This is not a purely visual problem: we want to maintain the state (e.g navigation bar hover, search state) as well. Bringing in reparenting here is an overkill when React can already handle reconciliation just fine. It's just that we need a routing abstraction that doesn't opt you out of proper reconciliation by default.
"Magic transitions". Sometimes, there really isn't a way to transition properly. Like actually different layouts. This is usually about animations specifically. However, in this case you often want to do it to completely different components anyway. There's no way to line them up. It's more of a layout animation or "magic move" use case where the source and the target might even be written by different people. Framer Motion does a version of this, and building some first-class support for this would be in scope of a React Animations project that we hope to get to in the future. However, that's not really related to the traditional React tree reparenting.

Now, this doesn't mean that reparenting is completely useless. There might be some use cases I've missed. But in many of these, a combination of the above four approaches together with more traditional approaches like lifting state up, is very likely sufficient. On the other hand, reparenting within the React tree raises so many deep questions that it's hard to justify the complexity.

It's just that we need a routing abstraction that doesn't opt you out of proper reconciliation by default.

Now someone please tell me that's out there already and I don't have to write it myself.

It's just that we need a routing abstraction that doesn't opt you out of proper reconciliation by default.

Now someone please tell me that's out there already and I don't have to write it myself.

router5 fits the bill I believe: https://router5.js.org/
I've always been a fan of its routing as state approach over the traditional routing as entry points approach taken by most client side routers. router5's author eloquently explains in his talk introducing router5, that routing as entry points is a pattern that was blindly adapted from server side routing, which is mostly stateless and transactional (i.e. an API request will only ever result in 1 route branch being exercised for the lifetime of the request), while client side routing is inherently stateful and dynamic (i.e. an SPA will need to keep track of its "current" route and often transition between many different routes and nested routes in a single browsing session), which is where much of the impedance mismatch comes from.
In more concrete terms, an app built with router5 would just have plain react components subscribing to routing state changes and branching accordingly with plain if/else/switch statements and/or map look-ups (this is the actual "routing" part) at any arbitrary depth in the component tree, instead of relying on special snowflake components (i.e. Routes and Routers) at the highest level of hierarchy responsible for branching between routes and rendering everything downstream.
It really is a shame that development on the project seems to have stalled. The concept itself is really simple though. I've been using a few custom routing utils in my own projects based on the same principles for a while. The entire routing logic fits in less than 100 lines and is super easy to reason about. Lately I've also been experimenting with adding some aspect of relative routing introduced by react-router v6 (IMHO that's one of the only redeeming ideas in there unfortunately, as the rest of it seems to be doubling down on routing as entry points), which so far seems to be a great fit but it will need a bit more battle testing.

Any progress on this issue?

The "tweet" (original parent) uses a ref to a DOM node, and places another DOM node into it. It portals the "video" (the child) into that second DOM node. Then, you can imperatively move that second DOM node anywhere in the DOM tree when needed, including reattaching it back.

saving refs so many levels deep sounds like the wrong way to go - I think it would be better to actually have an API for that.


[ADDED]:  EncryptionSystem using Java

Title and Issue number
Text Encryption System using java
Close #4065

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md

@TusharKesarwani Can you review the PR.


server side initialState

For server side rendering, the initialState is set thanks to:
const initialState = { posts: [], post: {} };

const store = configureStore(initialState);

Wouldn't be better to set initalState to null, so that the initialState is handled by reducers ?
Moreover, as it is a boilerplate, most people won't have posts in their app, and this initialState is a little hidden in server code.

Thank you for pointing out. We are making changes to file structure for v2 of MERN. I will fix this there. You can check out the roadmap discussion for v2 at #146.

Done on v2 branch.


Fix image not showing

Pull Request Test Coverage Report for Build 257

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 59.239%

Totals

Change from base Build 256:
0.0%

Covered Lines:
1292

Relevant Lines:
2181

💛  - Coveralls


[Incremental] Key hash caching

Builds on https://github.com/apple/swift-driver/pull/557 to also cache DependencyKey hashes. Saves another 10% according to one measured case.

@swift-ci please test

Could you also give me some more context for the 10% speedup? Are you seeing a 10% improvement in the cost of hashing, or 10% across the board? I think the most valuable metric here is the cost of insertion and lookup into hashed collections.

Could you also give me some more context for the 10% speedup? Are you seeing a 10% improvement in the cost of hashing, or 10% across the board? I think the most valuable metric here is the cost of insertion and lookup into hashed collections.

Assuming I did everything correctly, I tried an invocation of the compiler when the priors were present. I used three versions of the new driver, plus the old driver. Version 1 of the new driver was main, version 2: main + your intern version (I had to rebase), version 3: the other version of the new driver was main + your intern version + the hash optimizations (just as in this PR). Times reported by the time command.
old driver: 0.95 (user), 1.05 (total)
new driver (main): 1.6 (user), 1.77 (total)
new driver (main + intern): 1.10 (user), 1.24 (total)
new driver (main + intern + hash opts): 0.81 (user), 1.07 (total)
It is certainly possible I did something wrong; would love you to try the experiment for yourself. Contact me in Slack for details.

Closing in favor of https://github.com/apple/swift-driver/pull/560


Cached Transaction: Discard Transaction Modal

Task Description
Currently, we are showing an alert on the Send Confirmation Screen of a Cached Transaction when the UTXOs are invalid. Instead of showing an alert, we would rather like to have a Discard Cached Transaction modal to remain consistent with the rest of the UI.

Modals design placed in file now:
https://www.figma.com/design/m5eMFTKD391AiJAXaEzgxB/Bitcoin-Keeper?node-id=420-3528&t=RUw487RXh4bJhdBG-1

Using frame 725


problem

[1.1] “Appendix J: Multiple (Maximum and Range) Pooling Statistics in a Convolution Network” in the book, Understanding Deep Learning. Download from https://www.understandingdeeplearning.com
How can we apply multiple pooling as shown in [1.1] on any image data set.
Thanks..

hello git2120 have you solved it

@git2120 I think you could extend the idea presented in the book to do multiple pooling.
This is a good topic to be discussed in TF Forum as this GitHub repository is mainly focussed on Bugs and performance related issues.
Also, there is a big community ready to discuss and learn from each other. Thanks!


Docs: Add anchors to each heading

Finally! Closes #2411.

NICE!! I had no idea how to do this.

🎉 Actually got this deployed to the docs. 🎉

Actually this had some unintended side effects... 😅

That was an rude error from my part, sending PR to fix it... 😊


pkg(docker-engine): BINARY_SHORT_NAME deprecated

related to https://github.com/moby/moby/pull/43762
last nightly build failed with: https://github.com/docker/packaging/actions/runs/3213097052/jobs/5276739551#step:7:2616
#0 0.995 cmd/dockerd/config.go
#0 0.996 cmd/dockerd/config_windows.go
#0 0.997 cmd/dockerd/daemon.go
#0 0.997 cmd/dockerd/daemon_test.go
#0 0.997 cmd/dockerd/daemon_windows.go
#0 0.998 cmd/dockerd/docker.go
#0 0.998 cmd/dockerd/docker_windows.go
#0 0.998 cmd/dockerd/genwinres_windows.go
#0 1.001 2022/10/11 07:42:18 open ../../cli/winresources/dockerd/winres.json: no such file or directory
#0 1.007 cmd/dockerd/genwinres_windows.go:1: running "go-winres": exit status 1

@thaJeztah Could you backport https://github.com/moby/moby/pull/43762 to 22.06 maybe?
Signed-off-by: CrazyMax<EMAIL_ADDRESS>

Should already be in the 22.06 branch; https://github.com/moby/moby/blob/22.06/hack/make/.binary

Should already be in the 22.06 branch; https://github.com/moby/moby/blob/22.06/hack/make/.binary

Ah yes indeed sorry, was looking at https://github.com/moby/moby/tree/v22.06.0-beta.0 :persevere:


#1223 Removed EmptyProp value from points prop parsing

To better align how points should be parsed, the EmptyProp static variable that we used to indicate that a value was not set has been removed.
The new implementation throws an error if you try to parse / read a property that does not contain a point - this is how other props handles reading invalid values when nullptr is not a valid value.
In addition the Radius prop was rewritten to avoid raising this exception and handle radius as both number and vector in a correct way.
fixes #1223

awesome 💚
#1221 needs to be merge for this one to be green.


gitlab-formula updated

Hi,
Here are some additions / changes, making the formulas more configurable with more choices.

No hardcoded path : possibilty to install gitlab where you want
Use of original Postgresql / Nginx formulas
Original initd script from Gitlab setup
Proxy for git.latest / gem
Install package from archive
Configuration keys for secret_key and secret_file (gitlab_shell_secret)
Lot of little things...

Thanks for your work.

This is a pretty big change but looks okay to me on a first review.  I'm going to leave this open for others who may want to take a look. What operating systems have you tested this on?

Only Ubuntu 15.10.

Pull request update to Gitlab 9.4
Thx @EvaSDK

PR updated to 10.5 series


Error: Render frame was disposed before WebFrameMain could be accessed

Got tons of errors like this over tonight
ver 1.0.6
Ubuntu Linux
.....   tons of similar error before....
.....
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.097Z | HTTP | https://satom.ru | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.097Z | HTTP | http://admin.satom.ru/ | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.098Z | HTTP | http://admin.satom.ru/ | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.099Z | HTTP | http://admin.satom.ru/ | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.099Z | HTTP | http://admin.satom.ru/ | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.100Z | HTTP | https://service.egais.ru | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.100Z | HTTP | https://service.egais.ru | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.101Z | HTTP | https://egais.ru | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.101Z | HTTP | https://egais.ru | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
2022-05-04T04:49:53.102Z | HTTP | https://service.egais.ru | DOWN OR BLOCKED
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at EventEmitter._send (<anonymous>)
    at EventEmitter.n.send (node:electron/js2c/browser_init:165:417)
    at EventEmitter.b.send (node:electron/js2c/browser_init:161:2494)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:34:13638)
    at EventEmitter.emit (node:events:390:28)
    at Ot.emit (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45367)
    at EventEmitter.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45684)
    at EventEmitter.emit (node:events:390:28)
    at St.<anonymous> (/tmp/.mount_UA-CybjSg3tv/resources/app.asar/electron-main.js:1:45040)
    at Generator.next (<anonymous>)
Killed

Hej, sorry for the long response. First time seeing this issue :) Looks like something not related to the UACyberSHIELD, but the library under the hood.
There are a lot of similar issues on the internet related to the electron in different applications. Like Skype (it uses the same tech) https://answers.microsoft.com/en-us/skype/forum/all/skype-fails-to-launch/e85fddd3-9579-435a-8d90-3c0a4dd354a8 , but I may not be appliable to this case.
At the moment, I can't reproduce the bug, so it's very hard to find the problem and fix it :( . It may be only related to your PC, or maybe some very rare conditions :( . Maybe you have more info that will help to identify an issue, like after what actions it started to do this? If not, we have to wait for more reports from other users :(

Looks like bug in Electron engine...
eg: https://github.com/electron-userland/electron-builder/issues/6760


Recommended Motion Sensor

I noticed the Motion Sensor Pin setting in the configuration and code. Is there a recommended sensor that fits in the enclosure? Any pics of the install?

The hardware angle is still being worked out.  I posted a solution here: https://community.home-assistant.io/t/ha-switchplate-diy-lcd-touchscreen-wall-switch-replacement/25464/726
But there are still a fair amount of false positives and the sensor performance is flakey.  Others have used a PIR sensor which works but for which there isn't any particularly good option for mounting that I've worked out yet.  Still, I think the code is useful for those looking to experiment with different hardware solutions.


Writing coordinates to CFF glyph

I can read a set of coordinates from a CFF glyph using a RecorderPen. What is the best/right way to write them back into a CFF glyph? Is there an example for this?

With T2CharStringPen.

Thanks, that's a helpful pointer. And then I can write the returned charstring into the font with something like font.["CFF "].cff.topDictIndex[0].CharStrings["g"]? Would that work?

It's a bit messy. Have a look how fontBuilder.py deals with it, perhaps that can point you in the right direction.

You can get the private dictionary and reuse in the pen:
fontname = cff.keys()[0]
cff = otf["CFF "].cff
cffFont = cff[fontname]
cffFont.decompileAllCharStrings()
globalSubrs = cff.GlobalSubrs
topDict = cffFont
private = cffFont.Private
charStrings = cffFont.CharStrings
charStringsIndex = cffFont.CharStrings.charStringsIndex
strings = cffFont.strings

That's it, thank you! Would you believe what I was missing was the capital P in Private.

Hi @simoncozens did you manage to do it without FontBuilder.py ? Would you like to share your code ? I don't understand the private dict stuff... I'm stuck here : font.["CFF "].cff.topDictIndex[0].CharStrings["g"] = pen.getCharString()

This was four years ago. I'm sorry, I can't remember what I was doing at the time or where to look.

oh ok, I've open a discussions, hope this will lead to something !


Python debugger will be “terminated” unexpectedly

using the remote SSH extension for remote debugging，
when vscode connected to the company's centralized development machine; (there's no similar problem connecting to my private remote computer.)
This problem seems to be caused by the timeout of which module, and sometimes after the debugging interaction button disappears unexpectedly, you can see that the debugging process is actually running through the command, and sometimes several unresponsive debugging terminals will be generated after several failures,

This is the output.

Can you give some more details about exactly what you are doing and exactly what happens?


fix: updated layout to be in par with vuetify 2.x

v-row is a wrapper component for v-col. It utilizes flex properties to control the layout and flow of its inner columns. [...] This is the 2.x replacement for v-layout in 1.x.
v-col is a content holder that must be a direct child of v-row. This is the 2.x replacement for v-flex in 1.x.
https://vuetifyjs.com/fr-FR/components/grids/#usage

/cc @kevinmarrec @aldarund


Validate genome browser page url (alternative PR)

An alternative to PR https://github.com/Ensembl/ensembl-client/pull/900
Description
This PR checks the validity of the focus object parameter, and of the location parameter in the genome browser page url before showing the genome browser image.
In contrast to https://github.com/Ensembl/ensembl-client/pull/900, this PR achieves this functionality by expanding GenomeBrowserIdsContext and encapsulating the validation logic inside of custom hooks.
What to check while reviewing
Stress-test all three variable parts of the genome browser url. Remember that so far we can have focus genes and focus locations. Remember, too, that we aren't allowing commas in location coordinates in the url

Examples to try while testing:

Use a chromosome name that doesn't exist for this species
Make the start parameter greater than the end parameter
Format the location incorrectly (e.g. omit the colon or the dash)

Related JIRA Issue(s)
https://www.ebi.ac.uk/panda/jira/browse/ENSWBSITES-314
Deployment URL(s)
http://url-validation-context.review.ensembl.org

If we add commas in the location it gets trimmed off and loads the genome browser. But the value that gets into the previously viewed is the raw input from the user. Check this one below

Also I see the new hooks inside the context directory. Wonder if it should go inside hooks dir?

Also I see the new hooks inside the context directory. Wonder if it should go inside hooks dir?

No, these two are only going to be used by by the GenomeBrowserIdsContext. I'll move GenomeBrowserIdsContext inside the folder that now contains the two new hooks.

Thanks. Still something is not right. I can show you tomorrow.


Workaround for iOS devices is no longer needed for the latest iOS version.

> iOS 8
I have discovered that iOS 8 now supports .vcf files.

So we need to reprogram the isIOS() function.

For previous versions of < iOS 8 we did a workaround
iOS had no support for .vcf (vcard) files. So I build a workaround that uses .icf (vcalender).

What is the status of this? I am testing with 1.18 now, and it does not seem to be fixed.


kibana5.5.0 install plugin failed.

Download zip file for 5.5.X.
but installation failed.
below is error message
bin/kibana-plugin install file:///esdemo-media/kibana-5.5.0-linux-x86_64/network_vis.zip
Attempting to transfer from file:///esdemo-media/kibana-5.5.0-linux-x86_64/network_vis.zip
Transferring 6607531 bytes....................
Transfer complete
Retrieving metadata from plugin archive
Plugin installation was unsuccessful due to error "No kibana plugins found in archive"
Also try to use git clone, but kibana start failed.

Can you download directly from the branch 5.5.x and try again?
The ZIP of releases has an error, i will delete it.
Thx

Did u mean git clone the 5.5.x branch? I will try it. Thanks!
2017-08-23 18:10 GMT+08:00 David Moreno Lumbreras<EMAIL_ADDRESS>:

Can you download directly from the branch 5.5.x and try again?
The ZIP of releases has an error, i will delete it.
Thx
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dlumbrer/kbn_network/issues/34#issuecomment-324284700,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APRMhDlAc2_04NKpSwc4V8jCLDQ51q4Mks5sa_qxgaJpZM4O82ML
.

git clone the 5.5.x branch. It worked.Great！
2017-08-24 10:35 GMT+08:00 YongGuang Chen<EMAIL_ADDRESS>
Did u mean git clone the 5.5.x branch? I will try it. Thanks!
2017-08-23 18:10 GMT+08:00 David Moreno Lumbreras <
<EMAIL_ADDRESS>
Can you download directly from the branch 5.5.x and try again?
The ZIP of releases has an error, i will delete it.
Thx
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dlumbrer/kbn_network/issues/34#issuecomment-324284700,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APRMhDlAc2_04NKpSwc4V8jCLDQ51q4Mks5sa_qxgaJpZM4O82ML
.


Can open Diagnose datails without Diagnoses

We can open diagnose details when we have no diagnoses at all: https://www.screencast.com/t/qQv1l2nM1
Related issue #268 https://waffle.io/RippleOSI/combined-development-view/cards/5bcdcb84f4c0a7004421f3b8

ok thanks @kuvakina
Think we can live with that for now, but ideas on how to resolve are welcome
@PhilBarrett any other view?

Thank you, @tony-shannon
We'll try to look into it

Raised in Helm: https://waffle.io/RippleOSI/combined-development-view/cards/5bcdf01f2c62d200576fd2fe


sendFile seems to add two tabs to the end of my files under specific circumstandes

What steps will reproduce the problem?
I am using the yii advanced template (latest version) and I am generating an .xlsx file (with phpspreadsheet) to export some data.
When i am logged in and using Chomium based browsers (Chrome, Edge Beta) and I download a file using Yii::$app->response->sendFile('test.xlsx')->send() there are 2 tabs added to the end of the file (0909 in Hex). This corrupts the file and I am unable to open it with Excel.
Here are both .xlsx files in Hex: https://imgur.com/a/DZTs7iD
The left was downloaded via sendFile, the right one is the original file on the server.

I have tested this with other Browsers ("old = not Chromium based" Edge, Firefox) and the download works as expected (no extra tabs).

When I am not logged in, using a Chromium based browser, the file works as expected.

I have tested the download with a simple text.txt file i uploaded via FTP. The file on the server does not contain extra tabs. When I download it without logging in, the file is fine. When I log in and download it via direkt linking ... the file ist fine. When I use the sendFile-method, the text file has two extra tabs at the end.

Additional info
Yii version: 2.0.28
PHP version: 7.0.33-0+deb9u5
Operating system: Debian 9, MariaDB 10.1.41, nginx 1.16.1

Addendunm: Is it possible that Firefox + Edge (old/current) honor the content-length of the file transmitted and thus cut of extra tabs but Chrom(e/ium) does not? That would explain the inconsistency  between browsers at least.

And the solution was: My i8n translations file (frontend/language/ had two tabs in front of the opening <?php tag, thus causing corrupted files. I did not know that this could have had anything to do with my sendFile problems.


Staging environment

Will be helpful to have a staging environment as more people use service and features become more complex to avoid major service disruptions and breaking changes. Potentially we can use our original Twilio number?

Hmm. A few things about this:

A staging env will cost money since we'll need to double pay for infra in AWS. So expect roughly 2x our current monthly AWS costs — an extra $40 a month at least.
Most of the bugs we'd prevent in a staging env can also be prevented via local testing. We're such a small operation, I think it's totally acceptable to just have a local dev env and a prod env ATM.

So I'd recommend tabling this for now.


limit apps and vizs by study or data type?

currently were limiting apps and vizs by project, but thats unlikely to be enough. i think its an open question though how to further constrain them..

for ex, dan wants a longitudinal analysis type app for mbio, which would only make sense for those studies which actually have collected data longitudinally..


JSON-ROA data ignored

Hi,
I'm trying to read JSON-ROA responses from an API that look like this:
{
	"_json-roa": {
		"filled_with": "lots of data"
	},
	"created_at": "2015-11-05T10:33:37.249Z",
	"creator_id": "a41b963a-e50e-40ad-9c37-dc5dfcc9a1de",
	"id": "c97e9d4c-aaff-415a-a996-4a7e79ce0c81",
}

A call to r.json() recognizes created_at, creator_id, and id correctly but ignores _json-roa.
r.text shows likewise only the last three nodes.
If I open and read the same JSON not as a server response but as a static file, parsing it is not problem.
Any ideas?
Best,
birk

If r.text only shows the last three nodes, that means that only the last three nodes are present. This means that for some reason the server is choosing not to send you that data.
You'll need to consult with your API documentation or server operator to determine why that data is absent.

Thanks for the quit response. If I do the same request in the shell via curl I do get all the data from the server.

So in this case the problem is likely to be one of user-agent filtering. Try using curl -v to see what headers curl sends, and then set the user-agent header to the same thing using requests.

The header it was … I used 'accept': 'application/json' but it has to be either 'accept': '*/*' or correctly 'accept': 'application/json-roa+json'.


Kira merge

Merged kira branch into this and did a couple changes.
Added middleware to the routes
Changed the location of a few routes from web to common since they are common to both backend and front-end

I'll go ahead and merge this. My apologies. 😅


Roll Flutter Engine from 5a824e22deb2 to a17f8d18f3a6 (8 revisions)

https://github.com/flutter/engine/compare/5a824e22deb2...a17f8d18f3a6
2024-04-09<EMAIL_ADDRESS>better output from engine layer unit test failures (flutter/engine#51975)
2024-04-09<EMAIL_ADDRESS>Revert "Roll Dart SDK from 78174b41ab0f to 7a5e410f982e (1 revision) (#51980)" (flutter/engine#51990)
2024-04-09<EMAIL_ADDRESS>[skwasm] Reify the SkPicture pointer as the right type. (flutter/engine#51991)
2024-04-09<EMAIL_ADDRESS>Reverts "Roll Dart SDK from 7a5e410f982e to db99af14c4bc (1 revision) (#51986)" (flutter/engine#51989)
2024-04-09<EMAIL_ADDRESS>Move the Dart SDK to //flutter/third_party/dart (flutter/engine#51917)
2024-04-09<EMAIL_ADDRESS>[macOS] Implement hit testing and handle platform view cursor changes (flutter/engine#43101)
2024-04-09<EMAIL_ADDRESS>Roll Dart SDK from 7a5e410f982e to db99af14c4bc (1 revision) (flutter/engine#51986)
2024-04-09<EMAIL_ADDRESS>Roll Dart SDK from 78174b41ab0f to 7a5e410f982e (1 revision) (flutter/engine#51980)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC chinmaygarde@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.