smartango

I wrote some kind of report about ReacJS day – Verona, October, 5th. But my pc blocked (TODO: buy a new pc, once I understand which), I did not saved the document. I taked a screenshot.

My experiment on React.context will focus on edit state of a page. Currently the page is made of various components and some are switchable to edit-mode and view-mode. I want to add constraint that only one element in a page is on edit mode, and also to add the behavior of switch-to-view-mode-on-ESC-key.

I should provide a value via EditState.provider : elementid

For this I need that every editable element have a unique id in the page.

Some faced it in https://github.com/facebook/react/issues/1137, the most immediate and simple proposed solution is
https://github.com/facebook/react/issues/1137#issuecomment-95699269

But I will skip this problem passing a register function

const EditStateContext = React.createContext( {
   editElement: null,
   register: () => {}, // return an unique id
   editModeOn: (id) => {}, // toggle on
   editModeOff: (id) => {} // toggle off
})

as documented the value should be the state of a containing component

import { EditStateContext } from './EditStateContext';
class App extends React.Component {
  constructor(props) {
    super(props);
    this.editableComponents = [];
    this.register = () => {
	let newLength = this.editableComponents.push(this.editableComponents.length);
	return newLength - 1; // this is enough to stay safe on race condition
    }
    this.editModeOn = (id) => {this.setState({editElement:id})}
    this.editModeOff = (id) => {this.setState((oldState) => { if (oldState.editElement ===id) {return {editElement:id} }} )}
    this.state = {
	// about js lang I dislike the use of -1 for notFound of indexOf, but ...
	editElement: -1,
	register: this.register,
	editModeOn: this.editModeOn,
	editModeOff: this.editModeOff
    }
  }
  componentDidMount() {
	document.addEventListener('onkeyup',(e) => {
		if (e.code === 'ESC') { // Replace with something meaninful
			this.setState(state=>{ return {editElement: -1 }} ));
		}
	});
  }
  render() {
	return (
		<EditStateContext.Provider value={this.state}>
		  <Content />
		</EditStateContext.Provider>
	);
  }
}

The consumer will receive the value

import { EditStateContext } from './EditStateContext';

function withSkipEditableEl(Element) {
   return (
	<EditStateContext.Consumer>
		{ (props) => (<Element ...props />) }
	</EditStateContext.Consumer>
   )
}

Now I can use that HOC function passing the editable element.

It may works, I will test tomorrow.

I am still confused about contexxt and a number of pending tasks on the go.

Running a docker container from inside a docker container, I mean.

Of course one can define an image that instanciate a container as its default command, and this would lead to an infinite loop of forks … let’s see

The infinite containment

docker run -v /var/run/docker.sock:/var/run/docker.sock -name whocare alwaysfork

Ok, that is bad and I will not describe.

Container near a container

Maybe it is a bad thing, but most of the time docker and container is used interchangely, so I would had better written docker near a docker, that is cool.

What is near and why not “in”? it is like the infinite containment example, it is near because every contained execution is managed by the main daemon (dockerd) running in the host machine.

In fact in a infiniete containement you are not forking endless, but you are asking the dockerd to instanciate endlessly a new container, there is nothing that make one of the container a manager of the other, or a more authoritative manager than the other: every container that can access the /var/run/docker.sock socket and has the right can stop/remove every container in the machine.

Security concerns

I am not expert of security concerns, but everytime you do something “strange” there are great chances that that “strangeness” could lead to a security hole. (not being an expert I think even “not-strange” done by me can imply bad things)

Here the problem is due to the way docker is managing user, and mostly by how it manage the uid=0, root. The command by itself run the image standard command, and it is expected that the Dockerfile specify USER that will run the default command (and that is something != root).

But the weird part here is that being actually a container-near-container situation, at every instanciate point it could be switched to root with a

docker exec -u root -it myfunnyimage ./abadcommandforyou

this could be run from any container, call it aquitecontainer, all that is needed is the docker command in the image of aquitecontainer and that the socket is mounted as -v /var/run/docker.sock:/var/run/docker.sock and … so?

So you can switch to root from a container not running as root, because you can see the socket, and this is enough.

Two case are given:

1. the containing container is running as root, so no particular needs to access the socket
2. the containing container is running as a unprivileged user, but it has access to socket, so no particular needs to access the socket from the anyuserisused inside
3. the containing container is instanciated by root, but running as unprivileged user, that again map to the calling user, that is root

Yes, the problem here is that docker daemon always map the “no-root” user to the uid of the user that call its api.

But really it is not enough

In fact to access /var/run/docker.sock a user must be part of docker group, when a container is instanciated with its default user the groups are not migrated, so the image’s definition of user’s group membership is something to take into account: if internal user of the docker has no access to the docker.sock it can not communicate with the dockerd running, so no more docker in docker, no more root migration

I need some moment to fully understand this:

const compose = ( ...fns ) => fns.reduce( ( f, g ) => ( ...args ) => f( g( ...args ) ) );

reduce method is trickly: when initialValue is not given, the first element of the array is taken as first argument of reduce’s callback parameter, so f is the first argument, g is the second, (…args) is the formal parameters (passed to the resulting function), at the end of the reduction all …fns are applyied in reverse order (i.e. compose(f,g,h) g is applyed before f, and h is applyed before g, resulting in (…args) => f(g(h(…args)) ).

But once I got it it happen to be really an elegant way to write it:

const $d = $data.mergeMap( compose(Rx.Observable.from, r=>r.split('\n')) );

and not:

const $d = $data.mergeMap(r=>Rx.Observable.from(r.split('\n')));

that is less readable

Probabilmente in ritardo col resto del mondo, h chiarito un punto importante riguardo gli observable, e l’ho capita usando observable-redux. Prendo nota.

Definendo un Epic, da uno stream di action$ si restituisce un’altro stream di action

La Epic è eseguita dopo che il relativo reducer ha fatto il suo lavoro.

È possibile, data una action, restituirne un’altra, tramite .map()
in tal caso l’oggetto da restituire è proprio una action

È possibile inoltre restituire uno stream (un observable) che restituisce una (o più) action, in questo caso
si deve usare il metodo mergeMap()

Es.:

const loadOrdersEpic = (action$, store) => {
  return action$
  .ofType('LOADORDERS')
  .flatMap( () => { Observable.from(ajax('req')) })
  .mergeMap((res) => {
    return Observable.merge(
      Observable.of({type:'SUCCESSFULL.NET'}),
      Observable.of({type:'DATAREADY', res})
      );
    });
}

a differenza di map posso comporre degli observable(s) quindi generare più action (ovvero uno stream che genera più action)

const loadOrdersEpic = (action$, store) => {
  return action$
  .ofType('LOADORDERS')
  .flatMap( () => { Observable.from(ajax('req')) })
  .map((res) => {
    return {type:'DATAREADY', res}
   });
}