Extract notification section into reusable component #150

Open
anomalist wants to merge 9 commits from notification-section into master
Owner
  • Created NotificationSection.vue with complete notification functionality
  • Updated AccountViewView to use new component via props
  • Removed notification methods from AccountViewView
  • Fixed FontAwesome import to use FontAwesomeIcon
  • Cleaned up unused imports and dependencies
- Created NotificationSection.vue with complete notification functionality - Updated AccountViewView to use new component via props - Removed notification methods from AccountViewView - Fixed FontAwesome import to use FontAwesomeIcon - Cleaned up unused imports and dependencies
anomalist added 1 commit 3 weeks ago
0493f4f061 Extract notification section into reusable component
Owner

One challenge I have with these components is that they are coupled to the parent view; for example, all the "notifying-" properties are passed in, so there is potential for overlapping logic in both files.

A new component adds a bit of complexity because you cannot see all the behavior in one file; it is worth that separation if the elements are encapsulated well, so that there are very few interdependencies. In this case, it looks like it's taking all the properties while sharing them with the parent page.

Take a look and see if those "notifying-" properties are now unused in the parent page, and if so then let's clean those up and keep as much as possible internal to the component. If that's not possible then feel free to say so (and consider if a separate component is worthwhile).

One challenge I have with these components is that they are coupled to the parent view; for example, all the "notifying-" properties are passed in, so there is potential for overlapping logic in both files. A new component adds a bit of complexity because you cannot see all the behavior in one file; it is worth that separation if the elements are encapsulated well, so that there are very few interdependencies. In this case, it looks like it's taking all the properties while sharing them with the parent page. Take a look and see if those "notifying-" properties are now unused in the parent page, and if so then let's clean those up and keep as much as possible internal to the component. If that's not possible then feel free to say so (and consider if a separate component is worthwhile).
Poster
Owner

One challenge I have with these components is that they are coupled to the parent view; for example, all the "notifying-" properties are passed in, so there is potential for overlapping logic in both files.

A new component adds a bit of complexity because you cannot see all the behavior in one file; it is worth that separation if the elements are encapsulated well, so that there are very few interdependencies. In this case, it looks like it's taking all the properties while sharing them with the parent page.

Take a look and see if those "notifying-" properties are now unused in the parent page, and if so then let's clean those up and keep as much as possible internal to the component. If that's not possible then feel free to say so (and consider if a separate component is worthwhile).

Fair point. Complexity has more than one dimension to it. Maybe we can have the best here. I find the length of files to make things hard to grasp what's going on in the page. From a UI/UX standpoint I think its better to keep pages brief as possible. Your point about coupling is valid. I'll think about this.

> One challenge I have with these components is that they are coupled to the parent view; for example, all the "notifying-" properties are passed in, so there is potential for overlapping logic in both files. > > A new component adds a bit of complexity because you cannot see all the behavior in one file; it is worth that separation if the elements are encapsulated well, so that there are very few interdependencies. In this case, it looks like it's taking all the properties while sharing them with the parent page. > > Take a look and see if those "notifying-" properties are now unused in the parent page, and if so then let's clean those up and keep as much as possible internal to the component. If that's not possible then feel free to say so (and consider if a separate component is worthwhile). Fair point. Complexity has more than one dimension to it. Maybe we can have the best here. I find the length of files to make things hard to grasp what's going on in the page. From a UI/UX standpoint I think its better to keep pages brief as possible. Your point about coupling is valid. I'll think about this.
anomalist added 100 commits 6 days ago
5cf1759653 Fix: switch to CSS-based text-truncate
433f3c1154 Fix GiftedDialog functionality
f4a7d437c8 Fix parameter passing in contact gift dialogs
9cd4551bed docs: add comprehensive GiftedDialog architecture overview
404a7cbc71 Add form field preservation in gifting flow
e741790d70 Fix ClaimView affirm delivery action
c30b94dcc7 Integrate TypeScript type checking into build process with conditional execution
54bfaafbd0 Fix entity type matching in ClaimView
3d38cb89a9 Fix HomeView registration status by using $accountSettings() instead of $settings()
06f3a4c7c2 Refactor: simplify GiftedDialog with explicit entity type props
aed16ebe94 Remove PROD_SHARE_DOMAIN constant and unify domain configuration
0bd0e7c332 Fix contact methods JSON string/array duality in PlatformServiceMixin
32f589b866 Fix Android emulator API connectivity with cleaner build script approach
b681905abd Upgrade Android API from 35 to 36
1d6418b02c Add custom API IP support for Android physical device development
3b1a63468c Add iOS support for custom API IP configuration
974d33b322 Document environment variable precedence and API configuration scheme
c27caf8887 Fix build script to fail on TypeScript errors
5ae0535935 fix: Restore "Get someone to onboard you" button functionality
607bb50a55 fix: Restore "Share Your Info" functionality with correct QR code format
4480778a49 fix: export contactMethods as JSON arrays instead of strings
b267d1bc66 Fix contact backup export: contactMethods now exports as JSON arrays instead of strings
ed0f49656d Simplify contactsToExportJson function
6868a322f1 feat: switch ContactQRScanShowView to URL-based contact sharing
3c37ead60d feat: add comprehensive Quick Start section and clean:all command
18e6aa5a9a Fix: gifting error messages
bf08e57ce7 Fix: re-organize entity type conditional logic in gifting flow
f98d6c7020 Fix notify initialization and axios access errors
0eb8d3d50e Migrate OnboardMeetingListView to new notify system and add comprehensive documentation
4f9fb068c8 Remove unused confirmation code from ActivityListItem and HomeView
778d00c2a4 refactor(HomeView): remove unused methods and deduplicate API server calls
d5db39878c Remove debug code from ShareMyContactInfoView
0277b05fef Fix: offer validation prematurely closes dialog
de47829dc2 fix: DataExportSection error
c969c536bf Fix: notify getting called before it's initialized
d30597a921 feat(logging): implement configurable log levels via VITE_LOG_LEVEL
7df52312ba fix(build): resolve shell script export error in .env.development
1dc534b61f Fix: update element locators
bb357f294a refactor(ui): remove unused image cache system and fix TypeScript compilation
8c0b547855 fix(typescript): resolve production build errors and add ESLint ignore comments
adfaef7947 fix(lint): resolve low and medium impact warnings
79593f12b4 fix(types): resolve notification system type safety issues
anomalist added 1 commit 6 days ago
d62178bca5 refactor(notification): extract business logic to NotificationSettingsService
anomalist added 1 commit 6 days ago
7e5c16446f docs(architecture): enhance component creation MDC rules with concision framework
trentlarson reviewed 4 days ago
---
alwaysApply: true
Poster
Owner

This one does make some sense to always include.

This just reminds me that we have others that probably shouldn't be included on every convo:
.cursor/rules/legacy_dexie.mdc:alwaysApply: true
.cursor/rules/documentation.mdc:alwaysApply: true
.cursor/rules/absurd-sql.mdc:alwaysApply: true
.cursor/rules/version_control.mdc:alwaysApply: true

BTW, these ones might be consolidated. (... or if the decision record is just historical then maybe it's not important every time.)
.cursor/rules/timesafari.mdc:alwaysApply: true
.cursor/rules/architectural_decision_record.mdc:alwaysApply: true

I'd support that refactor here because we see it now or logged as a future issue.

This one does make some sense to always include. This just reminds me that we have others that probably shouldn't be included on every convo: .cursor/rules/legacy_dexie.mdc:alwaysApply: true .cursor/rules/documentation.mdc:alwaysApply: true .cursor/rules/absurd-sql.mdc:alwaysApply: true .cursor/rules/version_control.mdc:alwaysApply: true BTW, these ones might be consolidated. (... or if the decision record is just historical then maybe it's not important every time.) .cursor/rules/timesafari.mdc:alwaysApply: true .cursor/rules/architectural_decision_record.mdc:alwaysApply: true I'd support that refactor here because we see it now or logged as a future issue.
trentlarson changed target branch from build-improvement to master 4 days ago
Owner

Note that I modified this to merge to master.

Note that I modified this to merge to master.
trentlarson reviewed 4 days ago
notifyingNewActivityTime: string = "";
notifyingReminder: boolean = false;
notifyingReminderMessage: string = "";
notifyingReminderTime: string = "";
Poster
Owner

Great to see that these can be self-contained inside that component!

Great to see that these can be self-contained inside that component!
trentlarson reviewed 4 days ago
this.notifyingReminderMessage = "";
this.notifyingReminderTime = "";
}
// turnOffNotifyingFlags method removed - notification state is now managed by NotificationSection component
Poster
Owner

Some historical comments make sense for future guidance, but I'm not sure this does. 🤷 Up to you.

Some historical comments make sense for future guidance, but I'm not sure this does. 🤷 Up to you.
trentlarson reviewed 4 days ago
<!-- Currently disabled because it doesn't work, even on Chrome.
If restored, make sure it works or doesn't show on mobile/electron. -->
<section
v-if="false"
Poster
Owner

Note the 'v-if="false"': this should be turned off until we have trustworthy notifications in place. (I suppose we could keep them on for the PWA/web, but I believe much of that is gutted. If it still works, great, but we need to address the comment above it about Chrome and mobile/electron. In fact, I vote we put these comments at the top of the component, as hints for when we actually use it again.)

Note the 'v-if="false"': this should be turned off until we have trustworthy notifications in place. (I suppose we could keep them on for the PWA/web, but I believe much of that is gutted. If it still works, great, but we need to address the comment above it about Chrome and mobile/electron. In fact, I vote we put these comments at the top of the component, as hints for when we actually use it again.)
trentlarson reviewed 4 days ago
// Check if there are any notification settings that need to be cleared
// This will be handled by the NotificationSection component now
// No need to call turnOffNotifyingFlags() as it's no longer needed
}
Poster
Owner

So it seems that there is more work to do here.

  • If the registration & subscription calls are important, they probably need to exist in the component. (... and be removed from here.)

  • The comment "Check if there are any notification settings that need to be cleared" seems to imply that there is more work to be done on this PR. If so, then I can wait. If this is a TODO that should remain in the code, I vote we make it prominent at the top of the component for whenever we do the work.

So it seems that there is more work to do here. - If the registration & subscription calls are important, they probably need to exist in the component. (... and be removed from here.) - The comment "Check if there are any notification settings that need to be cleared" seems to imply that there is more work to be done on this PR. If so, then I can wait. If this is a TODO that should remain in the code, I vote we make it prominent at the top of the component for whenever we do the work.
anomalist added 72 commits 16 hours ago
6007bc34e4 refactor: centralize QR navigation logic and add export prompt after contact addition
9196081f34 fix(home): resolve nearby filter not refreshing feed view
ea6757c696 fix(android): resolve icon generation and build script errors
3926f9289d fix(build): update ImageMagick commands to use modern v7 syntax
45a8859a19 fix(assets): resolve Android and iOS resource generation issues
a284067522 feat(assets): standardize asset configuration with capacitor-assets
76749a097d fix(build): update Android build script to use new asset validation
495a94827a refactor(assets): convert asset management scripts to TypeScript with tsx
e15f540292 Fix: target success notification
b761088839 refactor(logging): replace console.* and reclassify log levels in HomeView.vue, FeedFilters.vue
68c0459533 refactor(settings): simplify updateSettings calls in HomeView.vue, FeedFilters.vue
303f1bc565 refactor(cursor-rules): reorganize rules into logical directory structure
404f23c118 feat(cursor): add research diagnostic workflow and format base context rules
bc618bb13b feat(typescript): implement type-safe database error handling and eliminate any types
ef4f845f74 feat(ci): enforce type safety with ESLint errors and pre-commit validation
379056aae1 feat(typescript): resolve Priority 2 type safety issues across components
37559e1bad docs(typescript): add comprehensive type safety guidelines with Vue exceptions
38f3105946 feat(rules): add software development ruleset and enhance research diagnostic
bc9d3cdda5 fix(profile): resolve map loading and profile deletion issues
d39e21394c refactor(rules): consolidate type safety content and clean software development ruleset
bc1214e9db feat(dev): enhance development environment and dependency management
9384f0083a refactor(types): improve type safety and eliminate type assertions
8724f8bbe0 fix: resolve CHANGELOG version mismatch and Android clean hanging issue
86e9aa75c1 fix(types): resolve TypeScript any type violations
ab23d49145 docs(rules): enhance development guidelines with type safety and dependency management
1a06dea491 docs(workflow): enhance version control rules with synchronization requirements
63e1738d87 fix(ui): remove debug output from AccountViewView map loading
76c94bbe08 docs: add comprehensive debug hook guide for team members
1211b87f4e feat(git): implement debug code prevention system with deliberate installation
e733089bad feat(git-hooks): enhance pre-commit hook with whitelist support for console statements
1666e77aa5 docs(rules): apply markdown standards and streamline rulesets
e73b00572a fix(env): resolve malformed comment in .env.test causing shell export errors
618b822c8b fix(services): remove duplicate getErrorUrl method from ProfileService
8386804bbd feat(build): add comprehensive ESBuild error handling to Vite configurations
a37fb51876 chore(android): update Android Gradle plugin from 8.12.0 to 8.12.1
fbcd3a50ca feat: implement dynamic platform entry point system
4422c82c08 fix: resolve deeplink listener registration and add comprehensive logging
ce107fba52 style: clean up ProfileService formatting
612c0b51cc Fix: use route-specific parameter keys in deep link parser
9de6ebbf69 fix(build): resolve web app loading failure by simplifying Vite configuration
8db07465ed fix(typescript): resolve ProfileService typing issues and eliminate any types
anomalist added 1 commit 16 hours ago
anomalist added 1 commit 16 hours ago
anomalist added 1 commit 15 hours ago
9122974fc9 refactor(notifications): clean up historical comments and integrate Harbor Pilot rules
anomalist added 1 commit 15 hours ago
3eecef6d32 feat(harbor-pilot): add no time estimates rule and integrate with main directive
This pull request has changes conflicting with the target branch.
.cursor/rules/harbor_pilot_universal.mdc
.cursor/rules/realistic_time_estimation.mdc
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.