Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong naming convention used for error and isLoading props #188

Open
naisergic opened this issue Jun 21, 2019 · 2 comments
Open

wrong naming convention used for error and isLoading props #188

naisergic opened this issue Jun 21, 2019 · 2 comments

Comments

@naisergic
Copy link

naisergic commented Jun 21, 2019

while using the universal component if a developer pass an error props for its own handling of error in the component, then what happens is that in the npm itself we are using the error props and based on that props we are returning the error component.

error and isLoading is very common name we should rename those two props.

for e.g

import ShowData from '../ShowData/ShowData.async'
const MyComponent = ({error,data})=>{
return < ShowData error={error} data={data} />
}

ShowData.async.js>>>>>>>>.

const ShowData = universal(
import('./ShowData'),
);

export default ShowData;

@tstirrat15
Copy link

Can you clarify what you'd prefer? You can always rename a passed prop to avoid collisions. I can't say I've run into the same issue.

@naisergic
Copy link
Author

Yes we can rename the props but consider a scenario of a large project where they implement chunk loading approach in a later phase of a project and also each and every dev needs to be aware of this that we cant use this two props and when a new dev comes then also he need to keep this thing in mind.

It would be good if we can rename this two props to something like universalChunkError or something else which clearly identifies that this prop is being used in the module itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants