[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:
Blocks
is blocked by STRIPES-339 ui-users top-level settings should lo... Closed
is blocked by STRIPES-340 ui-items top-level settings should lo... Closed
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 STRIPES-339 Closed work.

<MaterialTypesSettings> will follow when I have done STRIPES-340 Closed .

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 STRIPES-340 Closed .

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.

Generated at Thu Feb 08 23:06:53 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.