Pnpjs: npm package for React hooks

Created on 5 May 2020  路  12Comments  路  Source: pnp/pnpjs

Category

  • [X] Enhancement
  • [ ] Bug
  • [ ] Question
  • [ ] Documentation gap/issue

Version

Please specify what version of the library you are using: [ 1.10+ ]

Please specify what version(s) of SharePoint you are targeting: [ SPO ]

Enhancement

Is there any on-going work, or any interest in an npm package for React Hooks that provide SharePoint/M365 functionality? Something like @pnp/sp-react-hooks

discussion

Most helpful comment

I think having the conversation here is fine. We would need an understanding of what you want to build, who will maintain it, and what you want to call the repo (usually to match the package name as possible). We can then get that created and get you setup with the right perms and off you go.

All 12 comments

Hi @pschaeflein,

No, there is no ongoing work or any plans in such a package.
There was a sort of similar request. But, TBH, a package of PnPjs for React Hooks is a bit vague. Can you elaborate on the idea behind it? And what the difference in compare to the standard and generic useEffect approach?

Let's say I write some code that would be useful to others, like getting the current context / theme, or the hooks already packaged in some of the sample webparts. Rather than copy/paste from those projects, I would npm install and off I go.

To be clear, this is not an update or re-packaging of the pnpjs stuff. Just a package under the @pnp org in npm.

Oh, got it. You mean Reusable React Hooks library for SP/M365 development not necessarily related to REST/Graph, API consumption, and PnPjs but scoped to PnP initiative as React Reusable controls project for example.

It's definitely not in the scope of PnPjs repository but a dedicated story. And with a new package comes new responsibility. This should be considered. As the last we'd want is an abandoned package which no one maintains. Also, for a new package, there should be an existing basis otherwise it could end up with a forever empty one.

I'd suggest not throwing away the idea immediately but keep discussion opened. However, there were no plans for a library with hooks collection, in my knowledge. And I don't know a person who'd considered driving such a project in PnP initiative currently.

Absolutely happy to hear more, if we want to start building a common React Hook library and the push that out for reuse. Seems reasonable and we do provide home for these kind of initiatives under the PnP organization absolutely... anything we can do to help on providing more visibility for new open-source and community driven initiatives.

So, where is the place to have this conversation?

I think having the conversation here is fine. We would need an understanding of what you want to build, who will maintain it, and what you want to call the repo (usually to match the package name as possible). We can then get that created and get you setup with the right perms and off you go.

I am proposing a library of react hooks to support common tasks coded to interface with the M365 online services. React hooks are proven to reduce code ceremony (such as prop drilling) and have proven to be valuable in my code.

Initially, I have ideas for the following SharePoint-focused hooks:

  • useSharePointServiceScope
  • useSharePointContext
  • useSharePointTheme
  • useMSGraphClient
  • useAADHttpClient
  • useHttpClient
  • useSPListData

I am happy to be a maintainer of this project and welcome any advice/support from the PnP team.

As to the repo/package, I would think it would be included with the packages in this repo. But I'm flexible on that. Whatever aligns best with the PnP team.

I propose the package to be named @pnp/sp-react-hooks, with potential future packages aligned with other hosts (Teams, Office, etc.)

(Would be nice to be listed on this page:
image

IMO this would makes sense as its own repo under the pnp org. You can deploy to @pnp org on npm once we get the permissions setup. This repo is focused on the set of interrelated libraries that share common build tooling and dependencies and don't target a specific framework. From the outline it looks like you want to have that supports SPFx (awesome) but doesn't really relate to the work in this particular repo. You can then publish your own docs using gh pages (or whatever). If that sounds good to you I can check with the rest of the core team and get back to you about the best path forward. Thanks!

Yup, sounds fine. Thanks!

Awesome, this'll be cool. It's what I was pointing towards in https://github.com/pnp/pnpjs/issues/1100. @pschaeflein just explained it much better 馃殌

Following up on this after getting back from family leave - the way we'd like to approach this is for you (@pschaeflein) to get things started in your own repo. Then it has a chance to get built and grow a bit. Once it is established we can potentially look at bringing it in to the pnp org. Happy to help promote the work throughout the process.

Reasoning is that 1) it doesn't exist yet so creating a repo that potentially just sits empty is not desirable and 2) with no history (the code, not you) we don't know that it will be maintained beyond initial creation.

Let us know once you have something you're able to demo on a call and we can get it scheduled.

In the two months since my proposal, I have not seen anything that hints to a compelling need for a library. Thanks.

Was this page helpful?
0 / 5 - 0 ratings