Gathering detailed insights and metrics for react-service-locator
Installations
npm install react-service-locatorDeveloper Guide
BETA
Typescript
Yes
Module System
CommonJS
Min. Node Version
>=10
Node Version
16.13.1
NPM Version
8.4.1
Releases
Unable to fetch releases
Contributors
1
Unable to fetch Contributors
Languages
3
TypeScript
JavaScript
Shell
TypeScript (98.27%)
JavaScript (1.61%)
Shell (0.12%)
validate.email 🚀
Verify real, reachable, and deliverable emails with instant MX records, SMTP checks, and disposable email detection.
Developer
rhyek
Download Statistics
Total Downloads
31,147
Last Day
3
Last Week
25
Last Month
60
Last Year
3,224
GitHub Statistics
MIT License
22 Stars
30 Commits
2 Forks
1 Watchers
1 Branches
1 Contributors
Updated on Feb 01, 2024
Bundle Size
52.59 kB
Minified
12.29 kB
Minified + Gzipped
Maintainers
1
Package Meta Information
Latest Version
1.4.3
Package Id
react-service-locator@1.4.3
Unpacked Size
144.30 kB
Size
29.64 kB
File Count
60
NPM Version
8.4.1
Node Version
16.13.1
Total Downloads
Cumulative downloads
Total Downloads
31,147
Last Day
50%
3
Compared to previous day
Last Week
47.1%
25
Compared to previous week
Last Month
-46.9%
60
Compared to previous month
Last Year
-77.2%
3,224
Compared to previous year
Daily Downloads
Weekly Downloads
Monthly Downloads
Yearly Downloads
Peer Dependencies
2
Dev Dependencies
22
React Service Locator
An implementation of the service locator pattern for React 16.13+ using Hooks, Context API, and Inversify.
Features
- Service containers defined via a
ServiceContainercomponent that usesInversify's Dependency Injection containers under the hood - Support for hierarchical DI using nested
ServiceContainers including the capability of overriding services - Support for stateful services with reactivity when extending
StatefulService - Services are singleton-scoped by default, but transient is supported for
useClassanduseFactory - Excellent TypeScript support throughout
Setup
1npm install react-service-locator reflect-metadata
Modify your tsconfig.json to enable experimental decorators:
1{ 2 "compilerOptions": { 3 "experimentalDecorators": true, 4 "emitDecoratorMetadata": true 5 } 6}
Import reflect-metadata in your app's entrypoint (for example index.tsx):
1import 'reflect-metadata';
Basic Usage
Place a <ServiceContainer> in the component tree:
1import { ServiceContainer } from 'react-service-locator'; 2... 3 4function App() { 5 return ( 6 <ServiceContainer> 7 <SignInPage /> 8 </ServiceContainer> 9 ); 10}
Define a service:
1import { Service, Inject } from 'react-service-locator'; 2 3@Service() 4export class SessionService { 5 // Dependency injection is handled by Inversify internally 6 @Inject(HttpService) 7 private readonly httpService; 8 9 public login = async (username: string, password: string): Promise<void> => { 10 await this.httpService.post('/login', { username, password }); 11 }; 12}
Obtain the service:
1import { useService } from 'react-service-locator'; 2... 3 4export function SignInPage() { 5 // Service location is handled by Inversify internally 6 const sessionService = useService(SessionService); 7 8 return ( 9 <button onClick={() => sessionService.login('john', 'hunter2')}> 10 Sign In 11 </button> 12 ); 13}
Registering Services
Using the Service decorator
By default, all classes decorated with @Service are automatically registered in the service container. The decorator receives two optional parameters: provide and scope. If not specified, provide will be the target class and scope will be singleton:
1@Service() 2class HttpService {}
is equivalent to:
1@Service({ provide: HttpService, scope: 'singleton' }) 2class HttpService {}
For more control, you can also register services on the <ServiceContainer>:
1function App() { 2 return ( 3 <ServiceContainer 4 services={[ 5 SessionService, // shorthand 6 { 7 // same as shorthand 8 provide: SessionService, 9 useClass: SessionService, 10 scope: 'singleton', // optional 11 }, 12 { 13 provide: someSymbol, // token can be an object, string, or symbol 14 useFactory: (context) => 15 new SessionService(context.container.get(ServiceB)), 16 scope: 'transient', 17 }, 18 { 19 provide: 'tokenB', 20 useValue: someInstance, 21 }, 22 ]} 23 > 24 <Foo /> 25 </ServiceContainer> 26 ); 27}
Note: Services registered on the
<ServiceContainer>will override those registered with just the decorator if they have the same token.
Scopes
All forms of service registration are singleton-scoped by default. useClass and useFactory forms support a scope option that can be set to either singleton or transient. Shorthand and useValue forms will always be singleton-scoped.
Obtaining Services
useService hook
You can obtain the service instance by simply doing:
1const service = useService(SessionService);
You can also explicitly specify the return type:
1// service will be of type SessionService 2const service = useService<SessionService>('tokenA');
useServiceSelector hook
You can use this hook to obtain a partial or transformed representation of the service instance:
1const { fn } = useServiceSelector(SessionService, (service) => ({ 2 fn: service.login, 3}));
This hook is most useful with Stateful Services.
Stateful Services
Stateful services are like normal services with the added functionality of being able to manage internal state and trigger re-renders when necessary. Let's modify our service and see how this works:
1import { Service, Inject, StatefulService } from 'react-service-locator'; 2 3@Service() 4export class SessionService extends StatefulService<{ 5 displayName: string; 6 idle: boolean; 7} | null> { 8 @Inject(HttpService) 9 private readonly httpService; 10 11 constructor() { 12 super(null); // initialize with super 13 } 14 15 // Can also initialize this way. 16 // constructor() { 17 // super(); 18 // this.state = null; 19 // } 20 21 get upperCaseDisplayName() { 22 return this.state?.displayName?.toUpperCase(); 23 } 24 25 public async login(username: string, password: string): Promise<void> { 26 const { displayName } = await this.httpService.post('/login', { 27 username, 28 password, 29 }); 30 this.setState({ 31 // value is type checked 32 displayName, 33 idle: false, 34 }); 35 } 36 37 public setIdle(idle: boolean) { 38 this.setState({ idle }); // can be a partial value 39 } 40}
Stateful Services and useService hook
When using useService to obtain a stateful service instance, every time this.setState is called within that service, useService will trigger a re-render on any component where it is used.
We can avoid unnecessary re-renders by providing a second parameter (depsFn) to useService:
1export function Header() { 2 const sessionService = 3 useService(SessionService, (service) => [service.state.displayName]); 4 ... 5}
Now, re-renders will only happen in the Header component whenever state.displayName changes in our service. Any other change to state will be ignored.
depsFn receives the entire service instance so that you have more control. The function must return a dependencies list similar to what you provide to React's useEffect and other built-in hooks. This dependencies list is shallow compared every time this.setState is called.
Stateful Services and useServiceSelector hook
Another way to obtain a stateful service besides useService is with useServiceSelector. This hook will behave the same way as when called with non stateful services, but additionally it will trigger a re-render whenever this.setState is called and if and only if the result of selectorFn has changed.
1const { name } = useServiceSelector(SessionService, (service) => ({ 2 name: service.state.displayName, 3}));
Compare function
If selectorFn's result is a primitive value it will be compared with Object.is. If it is either an object or array, a shallow comparison will be used.
You can provide an alternative compare function as an optional third parameter, if needed.
Why one or the other?
The main difference between useService and useServiceSelector is that the former will always return the entire service instance, while the latter will only return the exact result of its selectorFn which can be anything. With useService the depsFn can define a set of dependencies for re-renders while still giving you access to everything the service exposes. This can be good in some cases, but it can potentially lead to situations where in your component you access some state that you forget to add to the dependency list which could result in stale UI elements.
With useServiceSelector you are forced to add everything you need in your component to the selectorFn result, so there's less room for mistake.
FAQ
-
Service locator? Isn't this dependency injection?
Although they are very similar, there is a slight difference between the two. With the service locator pattern, your code is responsible for explicitly obtaining the service through a known mechanism or utility. In our case we are using the
useServicehook as our service locator.More answers to the difference between the two here.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
- Info: project has a license file: LICENSE:0
- Info: FSF or OSI recognized license: MIT License: LICENSE:0
Reason
Found 0/30 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no SAST tool detected
Details
- Warn: no pull requests merged into dev branch
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
- Warn: no security policy file detected
- Warn: no security file to analyze
- Warn: no security file to analyze
- Warn: no security file to analyze
Reason
project is not fuzzed
Details
- Warn: no fuzzer integrations found
Reason
branch protection not enabled on development/release branches
Details
- Warn: branch protection not enabled for branch 'main'
Reason
24 existing vulnerabilities detected
Details
- Warn: Project is vulnerable to: GHSA-67hx-6x53-jw92
- Warn: Project is vulnerable to: GHSA-93q8-gq69-wqmw
- Warn: Project is vulnerable to: GHSA-grv7-fg5c-xmjg
- Warn: Project is vulnerable to: GHSA-3xgq-45jj-v275
- Warn: Project is vulnerable to: GHSA-w573-4hg7-7wgq
- Warn: Project is vulnerable to: GHSA-896r-f27r-55mw
- Warn: Project is vulnerable to: GHSA-9c47-m6qq-7p4h
- Warn: Project is vulnerable to: GHSA-952p-6rrq-rcjv
- Warn: Project is vulnerable to: GHSA-f8q6-p94x-37v3
- Warn: Project is vulnerable to: GHSA-xvch-5gv4-984h
- Warn: Project is vulnerable to: GHSA-5fw9-fq32-wv5p
- Warn: Project is vulnerable to: GHSA-hj48-42vr-x3v9
- Warn: Project is vulnerable to: GHSA-hrpp-h998-j3pp
- Warn: Project is vulnerable to: GHSA-p8p7-x288-28g6
- Warn: Project is vulnerable to: GHSA-gcx4-mw62-g8wm
- Warn: Project is vulnerable to: GHSA-c2qf-rxjj-qqgw
- Warn: Project is vulnerable to: GHSA-4rq4-32rv-6wp6
- Warn: Project is vulnerable to: GHSA-64g7-mvw6-v9qj
- Warn: Project is vulnerable to: GHSA-4wf5-vphf-c2xc
- Warn: Project is vulnerable to: GHSA-jgrx-mgxx-jf9v
- Warn: Project is vulnerable to: GHSA-72xf-g2v4-qvf3
- Warn: Project is vulnerable to: GHSA-j8xg-fqg3-53r7
- Warn: Project is vulnerable to: GHSA-6fc8-4gx4-v693
- Warn: Project is vulnerable to: GHSA-3h5v-q93c-6h6q
Score
1.7
/10
Last Scanned on 2025-03-03
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More