feature 262: refactor facts to uncouple from templating/blaze. #9629
Conversation
Wouldn't just having a weak dependency on Templating be easier than having two packages? |
AIUI It would not be equivalent: the included client part just does not work if By having separate packages, the 100% templating-related client part doesn't get to be included at all. Or am I missing something (entirely possible!) ? |
This now works in both client and server in a test application. A question bothers me, though: Is this expected ? Should it be modified to account for better conditions than |
Thanks very much for working on this @fgm! I've made a few comments inline, but have one additional item to mention. I think it makes sense to deprecate the
Thanks again! |
@@ -0,0 +1,75 @@ | |||
import { Facts, FACTS_COLLECTION, FACTS_PUBLICATION } from './facts_base_both'; | |||
|
|||
console.log('Facts base server'); |
hwillson
Feb 5, 2018
Member
Please remove this extra console.log
.
Please remove this extra console.log
.
fgm
Feb 9, 2018
•
Author
Contributor
Done
Done
api.use('ddp', 'server', {unordered: true}); | ||
|
||
api.mainModule('facts_base_server.js', 'server'); | ||
api.mainModule('facts_base_both.js', 'client'); |
hwillson
Feb 5, 2018
Member
Can you rename facts_base_both.js
(and all references) to something a little more open ended? "Both" refers to 2 items, which in this case sort of works semantically, because of client/server. "Both" might not always make sense however, so to future proof maybe use something like facts_base_common.js
(or even just common.js
).
Can you rename facts_base_both.js
(and all references) to something a little more open ended? "Both" refers to 2 items, which in this case sort of works semantically, because of client/server. "Both" might not always make sense however, so to future proof maybe use something like facts_base_common.js
(or even just common.js
).
fgm
Feb 9, 2018
Author
Contributor
Done
Done
@@ -0,0 +1,21 @@ | |||
Package.describe({ | |||
summary: "Publish internal app statistics", | |||
version: '0.0.1' |
hwillson
Feb 5, 2018
Member
Since this is a new package, let's start out at 1.0.0
.
Since this is a new package, let's start out at 1.0.0
.
fgm
Feb 9, 2018
Author
Contributor
Done
Done
api.mainModule('facts_base_server.js', 'server'); | ||
api.mainModule('facts_base_both.js', 'client'); | ||
|
||
api.export(['Facts', 'FACTS_COLLECTION', 'FACTS_PUBLICATION']); |
hwillson
Feb 5, 2018
Member
You shouldn't need to export FACTS_COLLECTION
and FACTS_PUBLICATION
here. The api.mainModule('facts_base_both.js', 'client');
call will take care of making these available to other packages, via import { FACTS_COLLECTION, FACTS_PUBLICATION } from 'meteor/facts-base';
.
You shouldn't need to export FACTS_COLLECTION
and FACTS_PUBLICATION
here. The api.mainModule('facts_base_both.js', 'client');
call will take care of making these available to other packages, via import { FACTS_COLLECTION, FACTS_PUBLICATION } from 'meteor/facts-base';
.
fgm
Feb 9, 2018
Author
Contributor
Done
Done
@@ -0,0 +1,34 @@ | |||
import { Facts, FACTS_COLLECTION, FACTS_PUBLICATION } from 'meteor/facts-base'; | |||
|
|||
console.log('Facts UI client'); |
hwillson
Feb 5, 2018
Member
Please remove this extra console.log
.
Please remove this extra console.log
.
fgm
Feb 9, 2018
Author
Contributor
Done
Done
@@ -0,0 +1,17 @@ | |||
Package.describe({ | |||
summary: "Display internal app statistics", | |||
version: '0.0.1' |
hwillson
Feb 5, 2018
Member
New package, so let's start at 1.0.0
.
New package, so let's start at 1.0.0
.
fgm
Feb 9, 2018
Author
Contributor
Done
Done
@@ -1,21 +1,12 @@ | |||
Package.describe({ | |||
summary: "Publish internal app statistics", | |||
version: '1.0.9' | |||
version: '1.0.10' |
hwillson
Feb 5, 2018
Member
I think that instead of bumping the version here and publishing a new version of the soon to be deprecated facts
package, that we should leave the facts
code and package.js
as is. We can add the deprecated notice to the README.md
like you have, but we should then also move this entire package into the packages/deprecated
directory. That way we can avoid making extra code changes here (and avoid publishing those changes) just to end up deprecating this package anyways.
I think that instead of bumping the version here and publishing a new version of the soon to be deprecated facts
package, that we should leave the facts
code and package.js
as is. We can add the deprecated notice to the README.md
like you have, but we should then also move this entire package into the packages/deprecated
directory. That way we can avoid making extra code changes here (and avoid publishing those changes) just to end up deprecating this package anyways.
fgm
Feb 9, 2018
Author
Contributor
Done
Done
|
||
// By default, we publish facts to no user if autopublish is off, and to all | ||
// users if autopublish is on. | ||
let userIdFilter = function (userId) { |
hwillson
Feb 5, 2018
Member
Hmm, I see what you mean about userId
(as mentioned in #9629 (comment)). It shouldn't be needed, so please feel free to remove it. This code hasn't been touched in 5 years, so it just looks like this was never noticed. As for making this more flexible (instead of just checking for Package.autopublish
), if you're interested in improving this, please feel free (as long as the existing functionality of checking for Package.autopublish
is preserved in some way, maybe as a default or fallback, for backwards compatibility).
Hmm, I see what you mean about userId
(as mentioned in #9629 (comment)). It shouldn't be needed, so please feel free to remove it. This code hasn't been touched in 5 years, so it just looks like this was never noticed. As for making this more flexible (instead of just checking for Package.autopublish
), if you're interested in improving this, please feel free (as long as the existing functionality of checking for Package.autopublish
is preserved in some way, maybe as a default or fallback, for backwards compatibility).
fgm
Feb 9, 2018
Author
Contributor
I think it is best to just leave it untouched for this PR since that would be an API feature change, while this PR is just about splitting code to remove dependencies. Can always be done once this gets in, without delaying for a different API design.
I think it is best to just leave it untouched for this PR since that would be an API feature change, while this PR is just about splitting code to remove dependencies. Can always be done once this gets in, without delaying for a different API design.
const packageFacts = factsByPackage[pkg]; | ||
if (!_.has(packageFacts, fact)) { | ||
factsByPackage[pkg][fact] = 0; | ||
} |
hwillson
Feb 5, 2018
Member
Thank you for adding these braces! 🙂
Thank you for adding these braces!
Looks good to me and works in my test application (client and server). I haven't touched the |
@hwillson just pinging to make sure you're aware the PR is ready to review. |
Sorry for the delay @fgm - I've scheduled some time for PR reviews later today, so I'll get back to this shortly. Thanks! |
Just rebased it and added the PR reference in |
Changes look great @fgm - thanks for working on this! |
How do I make use the fact package? |
@engrpeters the doc issue for this package is meteor/docs#33 |
As envisioned on meteor/meteor-feature-requests#262 :
facts
to separatefacts-base
andfacts-ui
packages to avoid thetemplating
dependency when not using the UI partfacts
package as a legacy compatibility wrapper to avoid breaking existing code