Open develomark opened 6 years ago
Hi @develomark!
Thanks for the positive feedback!
I understand didMount
sounds much more convincing to UI developers when they are using Proppy with React or Vue.
The reasonings behind naming it didSubscribe
was to stay as close to the API of Proppy itself, which allows subscribing to it from the instance:
const unsubscribe = p.subscribe(props => console.log(props));
To make things easier for anyone using this library, I propose having an alias for didSubscribe
, and call it didMount
like you suggested.
So the package would export both the functions, but didMount
would reference didSubscribe
:
import { didSubscribe, didMount } from 'proppy');
// didSubscribe is same as didMount
That makes sense to me.
Thank you for your response and feedback.
When the issue is picked up, the following need to be done:
didMount
// packages/proppy/src/index.ts
import { didSubscribe } from './didSubscribe';
export const didSubscribe = didSubscribe;
export const didMount = didSubscribe;
// packages/proppy/didMount.js
const didSubscribe = require('./lib/didSubscribe').didSubscribe;
module.exports = {
didMount: didSubscribe,
};
packages/proppy/README.md
site/content/api.md
In examples/react-playground
, mention didSubscribe
and didMount
together in the select field: https://codesandbox.io/s/github/fahad19/proppy/tree/master/examples/react-playground
Brilliant package. I really like this.
Please consider renaming didSubscribe to didMount so that it is crystal clear what this is doing.
I'm not sure it is clear immediately to users how this aligns to React or Vue. The fact that didSubscribe isn't handled server side means that 'For handling side-effects upon first subscription.' isn't true in every circumstance.
The added advantage is that new developers who have not seen proppy, but have used recompose should immediately understand what 'didMount' does.