chore: use log instead of console log #188
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reviewer's GuideReplaces direct console.debug usages with the central Log.debug helper across various components, hooks, and utilities, and wires in the Log import where needed to standardize debug logging behavior. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `src/application/awareness/dispatch.ts:50-56` </location>
<code_context>
const dispatchUser = useCallback(
(userParams: UserAwarenessParams) => {
if (!awareness) return;
const metadata: AwarenessMetadata = {
user_name: userParams.user_name || '',
cursor_color: userParams.cursor_color,
selection_color: userParams.selection_color,
user_avatar: userParams.user_avatar || '',
};
const awarenessState: AwarenessState = {
version: 1,
timestamp: dayjs().unix(),
user: {
uid: userParams.uid,
device_id: userParams.device_id,
},
metadata: JSON.stringify(metadata),
};
awareness.setLocalState(awarenessState);
// Log successful user awareness dispatch
Log.debug('📡 User awareness dispatched:', awarenessState);
},
[awareness]
);
return dispatchUser;
</code_context>
<issue_to_address>
**suggestion (code-quality):** Inline variable that is immediately returned ([`inline-immediately-returned-variable`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/inline-immediately-returned-variable))
```suggestion
return useCallback(
(userParams: UserAwarenessParams) => {
if (!awareness) return;
const metadata: AwarenessMetadata = {
user_name: userParams.user_name || '',
cursor_color: userParams.cursor_color,
selection_color: userParams.selection_color,
user_avatar: userParams.user_avatar || '',
};
const awarenessState: AwarenessState = {
version: 1,
timestamp: dayjs().unix(),
user: {
uid: userParams.uid,
device_id: userParams.device_id,
},
metadata: JSON.stringify(metadata),
};
awareness.setLocalState(awarenessState);
// Log successful user awareness dispatch
Log.debug('📡 User awareness dispatched:', awarenessState);
},
[awareness]
);
```
<br/><details><summary>Explanation</summary>Something that we often see in people's code is assigning to a result variable
and then immediately returning it.
Returning the result directly shortens the code and removes an unnecessary
variable, reducing the mental load of reading the function.
Where intermediate variables can be useful is if they then get used as a
parameter or a condition, and the name can act like a comment on what the
variable represents. In the case where you're returning it from a function, the
function name is there to tell you what the result is, so the variable name
is unnecessary.
</details>
</issue_to_address>
### Comment 2
<location> `src/application/awareness/selector.ts:121-127` </location>
<code_context>
const cursorsWithBaseRange = useMemo(() => {
if (!cursors.length || !editor || !editor.children[0]) return [];
const result = cursors.map((cursor) => {
const baseRange = convertAwarenessSelection(cursor.selection, editor.children);
return {
...cursor,
baseRange,
};
});
Log.debug('🎯 Final cursors array:', result);
return result;
}, [cursors, editor]);
return cursorsWithBaseRange;
</code_context>
<issue_to_address>
**suggestion (code-quality):** Inline variable that is immediately returned ([`inline-immediately-returned-variable`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/inline-immediately-returned-variable))
```suggestion
return useMemo(() => {
if (!cursors.length || !editor || !editor.children[0]) return [];
const result = cursors.map((cursor) => {
const baseRange = convertAwarenessSelection(cursor.selection, editor.children);
return {
...cursor,
baseRange,
};
});
Log.debug('🎯 Final cursors array:', result);
return result;
}, [cursors, editor]);
```
<br/><details><summary>Explanation</summary>Something that we often see in people's code is assigning to a result variable
and then immediately returning it.
Returning the result directly shortens the code and removes an unnecessary
variable, reducing the mental load of reading the function.
Where intermediate variables can be useful is if they then get used as a
parameter or a condition, and the name can act like a comment on what the
variable represents. In the case where you're returning it from a function, the
function name is there to tell you what the result is, so the variable name
is unnecessary.
</details>
</issue_to_address>
### Comment 3
<location> `src/components/database/components/drag-and-drop/useDragContext.ts:50-54` </location>
<code_context>
</code_context>
<issue_to_address>
**issue (code-quality):** Avoid function declarations, favouring function assignment expressions, inside blocks. ([`avoid-function-declarations-in-blocks`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/avoid-function-declarations-in-blocks))
<details><summary>Explanation</summary>Function declarations may be hoisted in Javascript, but the behaviour is inconsistent between browsers.
Hoisting is generally confusing and should be avoided. Rather than using function declarations inside blocks, you
should use function expressions, which create functions in-scope.
</details>
</issue_to_address>
### Comment 4
<location> `src/components/database/components/grid/drag-and-drop/GridDragContext.tsx:52-56` </location>
<code_context>
</code_context>
<issue_to_address>
**issue (code-quality):** Avoid function declarations, favouring function assignment expressions, inside blocks. ([`avoid-function-declarations-in-blocks`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/avoid-function-declarations-in-blocks))
<details><summary>Explanation</summary>Function declarations may be hoisted in Javascript, but the behaviour is inconsistent between browsers.
Hoisting is generally confusing and should be avoided. Rather than using function declarations inside blocks, you
should use function expressions, which create functions in-scope.
</details>
</issue_to_address>
### Comment 5
<location> `src/components/database/components/grid/drag-and-drop/GridDragContext.tsx:74-78` </location>
<code_context>
</code_context>
<issue_to_address>
**issue (code-quality):** Avoid function declarations, favouring function assignment expressions, inside blocks. ([`avoid-function-declarations-in-blocks`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/avoid-function-declarations-in-blocks))
<details><summary>Explanation</summary>Function declarations may be hoisted in Javascript, but the behaviour is inconsistent between browsers.
Hoisting is generally confusing and should be avoided. Rather than using function declarations inside blocks, you
should use function expressions, which create functions in-scope.
</details>
</issue_to_address>
### Comment 6
<location> `src/components/database/components/property/select/useOptionDragContext.ts:53-57` </location>
<code_context>
</code_context>
<issue_to_address>
**issue (code-quality):** Avoid function declarations, favouring function assignment expressions, inside blocks. ([`avoid-function-declarations-in-blocks`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/avoid-function-declarations-in-blocks))
<details><summary>Explanation</summary>Function declarations may be hoisted in Javascript, but the behaviour is inconsistent between browsers.
Hoisting is generally confusing and should be avoided. Rather than using function declarations inside blocks, you
should use function expressions, which create functions in-scope.
</details>
</issue_to_address>
### Comment 7
<location> `src/components/database/components/settings/usePropertyDragContext.ts:58-62` </location>
<code_context>
</code_context>
<issue_to_address>
**issue (code-quality):** Avoid function declarations, favouring function assignment expressions, inside blocks. ([`avoid-function-declarations-in-blocks`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/avoid-function-declarations-in-blocks))
<details><summary>Explanation</summary>Function declarations may be hoisted in Javascript, but the behaviour is inconsistent between browsers.
Hoisting is generally confusing and should be avoided. Rather than using function declarations inside blocks, you
should use function expressions, which create functions in-scope.
</details>
</issue_to_address>
### Comment 8
<location> `src/components/editor/components/blocks/database/hooks/useRetryFunction.ts:37-43` </location>
<code_context>
const retryFunction = useCallback(
async (...args: T): Promise<R> => {
let attempt = 1;
const executeWithRetry = async (): Promise<R> => {
try {
if (!fn) {
throw new Error('Function not available');
}
const result = await fn(...args);
if (!result) {
throw new Error('No result returned');
}
return result;
} catch (error) {
if (attempt < RETRY_CONFIG.maxAttempts) {
const delay = RETRY_CONFIG.getRetryDelay(attempt);
Log.debug(`[useRetryFunction] Retry attempt ${attempt} after ${delay}ms`, error);
attempt++;
await new Promise(resolve => setTimeout(resolve, delay));
return executeWithRetry();
} else {
console.error(`[useRetryFunction] All ${RETRY_CONFIG.maxAttempts} attempts failed`, error);
onError();
throw error;
}
}
};
return executeWithRetry();
},
[fn, onError]
);
return retryFunction;
</code_context>
<issue_to_address>
**suggestion (code-quality):** Inline variable that is immediately returned ([`inline-immediately-returned-variable`](https://docs.sourcery.ai/Reference/Rules-and-In-Line-Suggestions/TypeScript/Default-Rules/inline-immediately-returned-variable))
```suggestion
return useCallback(
async (...args: T): Promise<R> => {
let attempt = 1;
const executeWithRetry = async (): Promise<R> => {
try {
if (!fn) {
throw new Error('Function not available');
}
const result = await fn(...args);
if (!result) {
throw new Error('No result returned');
}
return result;
} catch (error) {
if (attempt < RETRY_CONFIG.maxAttempts) {
const delay = RETRY_CONFIG.getRetryDelay(attempt);
Log.debug(`[useRetryFunction] Retry attempt ${attempt} after ${delay}ms`, error);
attempt++;
await new Promise(resolve => setTimeout(resolve, delay));
return executeWithRetry();
} else {
console.error(`[useRetryFunction] All ${RETRY_CONFIG.maxAttempts} attempts failed`, error);
onError();
throw error;
}
}
};
return executeWithRetry();
},
[fn, onError]
);
```
<br/><details><summary>Explanation</summary>Something that we often see in people's code is assigning to a result variable
and then immediately returning it.
Returning the result directly shortens the code and removes an unnecessary
variable, reducing the mental load of reading the function.
Where intermediate variables can be useful is if they then get used as a
parameter or a condition, and the name can act like a comment on what the
variable represents. In the case where you're returning it from a function, the
function name is there to tell you what the result is, so the variable name
is unnecessary.
</details>
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
josue693
pushed a commit
to josue693/AppFlowy-Web
that referenced
this pull request
Dec 21, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Checklist
General
Testing
Feature-Specific
Summary by Sourcery
Standardize debug logging across the app to use the shared Log utility instead of direct console.debug calls.
Enhancements:
Chores: