[STRIPES-338] First batch of stripes-connect logging uses in-built dummy logger Created: 02/May/17 Updated: 03/May/17 Resolved: 03/May/17 |
|
| Status: | Closed |
| Project: | Stripes |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Bug | Priority: | P3 |
| Reporter: | Mike Taylor | Assignee: | Mike Taylor |
| Resolution: | Done | Votes: | 0 |
| Labels: | sprint13 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 3 hours | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||
| Sprint: | |||||||||||||
| Description |
|
When logging into Stripes, the JS console shows: -- (connect) connecting <About> for '@folio/trivial' connect.js:194 stripes-connect (connect) connecting <PermissionSet> for '@folio/users' connect.js:194 stripes-connect (connect-no) not connecting <PermissionSetDetails> for '@folio/users': no manifest connect.js:194 stripes-connect (connect) connecting <PermissionSets> for '@folio/users' connect.js:194 stripes-connect (connect) connecting <PatronGroupsSettings> for '@folio/ui-users' connect.js:194 stripes-connect (connect) connecting <MaterialTypesSettings> for '@folio/ui-items' The first of these lines correctly uses stripes-core's configured logger, but the others use stripes-connect's tiny built-in dummy logger. Why? |
| Comments |
| Comment by Mike Taylor [ 02/May/17 ] |
|
It looks like the dummy logger is used for settings components, not top-level app components. |
| Comment by Mike Taylor [ 02/May/17 ] |
|
(By the way, this explains why the "connect-no" line is included even though I don't have that logging category enabled: it's because the tiny dummy logger that emits these lines doesn't know about categories.) |
| Comment by Mike Taylor [ 02/May/17 ] |
|
The settings modules get connected as follows:
const connect = connectFor(m.module, stripes.logger);
const Current = connect(m.getModule());
Which is not obviously wrong. |
| Comment by Mike Taylor [ 02/May/17 ] |
|
Oh – and it's not wrong! The problem is much simpler. This is happening with the components that connect themselves rather than allowing their callers to connect them using their module-specific curried-connect function. And the fix is to have them not do that. |
| Comment by Mike Taylor [ 02/May/17 ] |
|
And the fix for that it tied up with the conversion of the modules' top-level settings components so that they include lower-level modules by react-router rather than by manual state management. (I must file that as its own issue.) |
| Comment by Mike Taylor [ 02/May/17 ] |
|
Fixed for <PermissionSets> and <PatronGroupsSettings>, following on from the
<MaterialTypesSettings> will follow when I have done
The others – lower down in the Users settings hierarchy – need to be fixed manually. |
| Comment by Mike Taylor [ 02/May/17 ] |
|
Fixed for <MaterialTypesSettings>, following on from
|
| Comment by Mike Taylor [ 02/May/17 ] |
|
For the record, what remains to fix is: stripes (connect) connecting <About> for '@folio/trivial' stripes-connect (connect) connecting <PermissionSet> for '@folio/users' stripes-connect (connect-no) not connecting <PermissionSetDetails> for '@folio/users': no manifest stripes-connect (connect) connecting <ScanCheckoutSettings> for '@folio/ui-scan' It can wait till tomorrow. |
| Comment by Mike Taylor [ 03/May/17 ] |
|
All of these are fixed now, and the Scan module converted to use the new <Settings> component. |