New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature 262: refactor facts to uncouple from templating/blaze. #9629

Merged
merged 3 commits into from Feb 21, 2018

Conversation

Projects
None yet
5 participants
@fgm
Contributor

fgm commented Feb 2, 2018

As envisioned on meteor/meteor-feature-requests#262 :

  • extract logic from facts to separate facts-base and facts-ui packages to avoid the templating dependency when not using the UI part
  • keep the facts package as a legacy compatibility wrapper to avoid breaking existing code
@StorytellerCZ

This comment has been minimized.

Contributor

StorytellerCZ commented Feb 2, 2018

Wouldn't just having a weak dependency on Templating be easier than having two packages?

@fgm

This comment has been minimized.

Contributor

fgm commented Feb 2, 2018

AIUI It would not be equivalent: the included client part just does not work if templating is not included, but it is still being exposed by the package, although it doesn't work in that case, and it still present in the bundle.

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!) ?

@fgm fgm force-pushed the fgm:feature-262_refactor-facts branch from 8b33766 to ccd886d Feb 2, 2018

@fgm

This comment has been minimized.

Contributor

fgm commented Feb 2, 2018

This now works in both client and server in a test application. A question bothers me, though: userIdFilter takes a userId argument, but ignores it, instead just relying on the presence of autopublish to decide whether or not to publish this manually maintained (vs MongoDB) collection.

Is this expected ? Should it be modified to account for better conditions than autopublish ? Or, if this is to be maintained for compatibility, shouldn't it be made more flexible to expose the publication to any server-side code wishing to decide upon publication conditions itself ? And the userId parameter removed ?

@hwillson

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 facts package (see my comments), which means we should consider updating other packages that refer to it. Would you mind:

  • Updating the ddp-server package to use facts-base
  • Updating the mongo package to use facts-base

Thanks again!

@@ -0,0 +1,75 @@
import { Facts, FACTS_COLLECTION, FACTS_PUBLICATION } from './facts_base_both';
console.log('Facts base server');

This comment has been minimized.

@hwillson

hwillson Feb 5, 2018

Member

Please remove this extra console.log.

This comment has been minimized.

@fgm

fgm Feb 9, 2018

Contributor

Done

api.use('ddp', 'server', {unordered: true});
api.mainModule('facts_base_server.js', 'server');
api.mainModule('facts_base_both.js', 'client');

This comment has been minimized.

@hwillson

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).

This comment has been minimized.

@fgm

fgm Feb 9, 2018

Contributor

Done

@@ -0,0 +1,21 @@
Package.describe({
summary: "Publish internal app statistics",
version: '0.0.1'

This comment has been minimized.

@hwillson

hwillson Feb 5, 2018

Member

Since this is a new package, let's start out at 1.0.0.

This comment has been minimized.

@fgm

fgm Feb 9, 2018

Contributor

Done

api.mainModule('facts_base_server.js', 'server');
api.mainModule('facts_base_both.js', 'client');
api.export(['Facts', 'FACTS_COLLECTION', 'FACTS_PUBLICATION']);

This comment has been minimized.

@hwillson

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';.

This comment has been minimized.

@fgm

fgm Feb 9, 2018

Contributor

Done

@@ -0,0 +1,34 @@
import { Facts, FACTS_COLLECTION, FACTS_PUBLICATION } from 'meteor/facts-base';
console.log('Facts UI client');

This comment has been minimized.

@hwillson

hwillson Feb 5, 2018

Member

Please remove this extra console.log.

This comment has been minimized.

@fgm

fgm Feb 9, 2018

Contributor

Done

@@ -0,0 +1,17 @@
Package.describe({
summary: "Display internal app statistics",
version: '0.0.1'

This comment has been minimized.

@hwillson

hwillson Feb 5, 2018

Member

New package, so let's start at 1.0.0.

This comment has been minimized.

@fgm

fgm Feb 9, 2018

Contributor

Done

@@ -1,21 +1,12 @@
Package.describe({
summary: "Publish internal app statistics",
version: '1.0.9'
version: '1.0.10'

This comment has been minimized.

@hwillson

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.

This comment has been minimized.

@fgm

fgm Feb 9, 2018

Contributor

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) {

This comment has been minimized.

@hwillson

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).

This comment has been minimized.

@fgm

fgm Feb 9, 2018

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.

const packageFacts = factsByPackage[pkg];
if (!_.has(packageFacts, fact)) {
factsByPackage[pkg][fact] = 0;
}

This comment has been minimized.

@hwillson

hwillson Feb 5, 2018

Member

Thank you for adding these braces! 🙂

@fgm fgm force-pushed the fgm:feature-262_refactor-facts branch 2 times, most recently from 9bc5a65 to 42a97de Feb 8, 2018

@fgm fgm changed the title from [WIP] feature 262: refactor facts to uncouple from templating/blaze. to feature 262: refactor facts to uncouple from templating/blaze. Feb 9, 2018

@fgm

This comment has been minimized.

Contributor

fgm commented Feb 9, 2018

Looks good to me and works in my test application (client and server). I haven't touched the userIdFilter() part for now, as I think it needs to be given more thought.

@fgm

This comment has been minimized.

Contributor

fgm commented Feb 14, 2018

@hwillson just pinging to make sure you're aware the PR is ready to review.

@hwillson

This comment has been minimized.

Member

hwillson commented Feb 14, 2018

Sorry for the delay @fgm - I've scheduled some time for PR reviews later today, so I'll get back to this shortly. Thanks!

@fgm fgm force-pushed the fgm:feature-262_refactor-facts branch from 42a97de to 33f819c Feb 14, 2018

@fgm

This comment has been minimized.

Contributor

fgm commented Feb 14, 2018

Just rebased it and added the PR reference in History.md, BTW.

@hwillson

This comment has been minimized.

Member

hwillson commented Feb 15, 2018

Changes look great @fgm - thanks for working on this!

@benjamn benjamn merged commit fd63390 into meteor:devel Feb 21, 2018

17 checks passed

CLA Author has signed the Meteor CLA.
Details
ci/circleci: Docs Your tests passed on CircleCI!
Details
ci/circleci: Get Ready Your tests passed on CircleCI!
Details
ci/circleci: Group 0 Your tests passed on CircleCI!
Details
ci/circleci: Group 1 Your tests passed on CircleCI!
Details
ci/circleci: Group 10 Your tests passed on CircleCI!
Details
ci/circleci: Group 11 Your tests passed on CircleCI!
Details
ci/circleci: Group 2 Your tests passed on CircleCI!
Details
ci/circleci: Group 3 Your tests passed on CircleCI!
Details
ci/circleci: Group 4 Your tests passed on CircleCI!
Details
ci/circleci: Group 5 Your tests passed on CircleCI!
Details
ci/circleci: Group 6 Your tests passed on CircleCI!
Details
ci/circleci: Group 7 Your tests passed on CircleCI!
Details
ci/circleci: Group 8 Your tests passed on CircleCI!
Details
ci/circleci: Group 9 Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@benjamn benjamn added this to the Package Patches milestone Feb 21, 2018

@fgm fgm deleted the fgm:feature-262_refactor-facts branch Feb 21, 2018

@engrpeters

This comment has been minimized.

engrpeters commented Jul 8, 2018

How do I make use the fact package?

@fgm

This comment has been minimized.

Contributor

fgm commented Nov 2, 2018

@engrpeters the doc issue for this package is meteor/docs#33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment