feat(ojoi): Rejected state and improvements #16574
Conversation
…w application after they submit one.
WalkthroughThe pull request introduces significant enhancements to the Official Journal of Iceland application, focusing on search functionality and state management. Key changes include the addition of a new GraphQL query for retrieving application case details, modifications to existing components for better state handling, and the introduction of new input and response types. Additionally, various components have been updated to improve user interaction and layout, while localization messages have been refined for clarity. Overall, these changes streamline the application's functionality and improve the user experience. Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #16574 +/- ##
=======================================
Coverage 36.77% 36.78%
=======================================
Files 6856 6857 +1
Lines 142374 142400 +26
Branches 40611 40613 +2
=======================================
+ Hits 52364 52377 +13
- Misses 90010 90023 +13
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 3 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
Datadog ReportAll test runs ✅ 5 Total Test Services: 0 Failed, 5 Passed Test Services
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 62
🧹 Outside diff range and nitpick comments (52)
libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts (2)
1-4: Consider adding a description to the GraphQL object type.Adding a description to the GraphQL object type using the
@ObjectTypedecorator's description parameter would improve API documentation and developer experience.-@ObjectType('OJOIAApplicationCaseResponse') +@ObjectType('OJOIAApplicationCaseResponse', { + description: 'Response type for Official Journal of Iceland application case details' +})
1-22: Consider adding JSDoc comments for better documentation.While the GraphQL decorators provide schema documentation, adding JSDoc comments would improve IDE support and make the code more maintainable.
+/** + * Response type for Official Journal of Iceland application case details. + * Used by the GraphQL API to return application case information. + */ @ObjectType('OJOIAApplicationCaseResponse') export class OJOIAApplicationCaseResponse { + /** The department responsible for the application */ @Field() department!: string; // Add similar comments for other fields }libs/application/templates/official-journal-of-iceland/src/lib/messages/index.ts (1)
Line range hint
1-15: Consider organizing exports alphabetically.For better maintainability, consider organizing the exports alphabetically. The current order places 'rejected' at the end, while alphabetical ordering would place it between 'requirements' and 'signatures'.
export * from './attachments' export * from './error' export * from './general' export * from './advert' export * from './original' export * from './requirements' + export * from './rejected' export * from './preview' export * from './publishing' export * from './summary' export * from './signatures' export * from './comments' export * from './involved-parties' - export * from './rejected'libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx (1)
Line range hint
7-21: Consider using React Context for navigation.Since
goToScreenis being passed down through multiple components, consider using React Context to avoid prop drilling if this pattern continues to grow.Example implementation:
// NavigationContext.tsx import { createContext, useContext } from 'react' interface NavigationContextType { goToScreen: (screen: string) => void } const NavigationContext = createContext<NavigationContextType | undefined>(undefined) export const NavigationProvider = ({ children, goToScreen }) => ( <NavigationContext.Provider value={{ goToScreen }}> {children} </NavigationContext.Provider> ) export const useNavigation = () => { const context = useContext(NavigationContext) if (!context) { throw new Error('useNavigation must be used within NavigationProvider') } return context }libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (1)
3-23: LGTM! Well-structured message definitions.The message structure is clean and follows consistent naming patterns. The messages appropriately cover the rejected state scenario with clear, user-friendly content.
Consider adding type annotation to the export:
-export const rejected = { +export const rejected: RejectedMessages = {libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1)
Line range hint
9-21: Consider adding JSDoc documentation for the component props.To improve maintainability and make the component more self-documenting, consider adding JSDoc comments describing the purpose of the
goToScreenprop and other props fromOJOIFieldBaseProps.+/** + * Screen component for handling publishing-related configurations + * @param props.goToScreen - Function to handle navigation between screens + * @param props - Additional base props from OJOIFieldBaseProps + */ export const PublishingScreen = (props: OJOIFieldBaseProps) => {libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx (1)
6-6: LGTM! Consider adding JSDoc documentation.The type change to support React.ReactNode increases component flexibility while maintaining backward compatibility.
Add JSDoc documentation to clarify valid value types:
+ /** + * @property {string | React.ReactNode} value - The value to display. Can be a string or any valid React node. + */ value?: string | React.ReactNodelibs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (1)
Line range hint
1-33: Consider enhancing type safety and reusability.While the component follows basic TypeScript practices, there are opportunities for improvement:
- Consider extracting the file upload configuration into a shared constant
- Add explicit type for the file upload callback functions
Here's a suggested improvement:
// Add to a shared constants file export const FILE_UPLOAD_STYLES = { defaultFileBackgroundColor: { background: 'blue100', border: 'blue200', icon: 'blue200', }, } as const; // Add to types file export interface FileUploadCallbacks { onChange: (files: File[]) => void; onRemove: (fileToRemove: File) => void; } // Use in component export const Original = ({ application }: OJOIFieldBaseProps) => { // ... existing code ... return ( <Box> <InputFileUpload {...FILE_UPLOAD_STYLES} header={f(original.fileUpload.header)} description={f(original.fileUpload.description)} buttonLabel={f(original.fileUpload.buttonLabel)} fileList={files} accept={ALLOWED_FILE_TYPES} onChange={onChange} onRemove={onRemove} multiple={false} /> </Box> ) }libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts (1)
51-51: Consider using explicit property assignment for clarity.While the shorthand notation works, being explicit about the callback assignment could improve readability.
- onCompleted: onCompleted, + onCompleted: (data: TypesResponse) => { + if (onCompleted) { + onCompleted(data); + } + },libs/application/templates/official-journal-of-iceland/src/fields/CommunicationChannels.tsx (2)
Line range hint
32-37: Consider using React Context for channel management.The component is passing multiple related props through multiple levels. This could be simplified using React Context to avoid props drilling and make the component more maintainable.
Here's a suggested approach:
// channelContext.tsx interface ChannelContextType { channelState: ChannelState; setChannelState: (state: ChannelState) => void; isVisible: boolean; setIsVisible: (visible: boolean) => void; } export const ChannelContext = React.createContext<ChannelContextType | undefined>(undefined); export const ChannelProvider: React.FC = ({ children }) => { const [channelState, setChannelState] = useState<ChannelState>({ name: '', email: '', phone: '' }); const [isVisible, setIsVisible] = useState(false); return ( <ChannelContext.Provider value={{ channelState, setChannelState, isVisible, setIsVisible }}> {children} </ChannelContext.Provider> ); };
14-14: Add type annotation for the name state.While TypeScript can infer the type, explicit type annotations improve code maintainability and documentation.
-const [name, setName] = useState<string>('') +const [name, setName] = useState<string | undefined>('')libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1)
8-10: Consider enhancing TypeScript type safetyWhile the component is properly typed, consider these TypeScript enhancements:
-export const RejectScreen = (props: OJOIFieldBaseProps) => { +/** + * Screen component for displaying rejection state of an application + * @param props - Base props for OJOI field components + */ +export const RejectScreen = (props: OJOIFieldBaseProps): JSX.Element => {libs/application/templates/official-journal-of-iceland/src/screens/AdvertScreen.tsx (4)
Line range hint
10-11: Define and export prop types for better reusabilityThe component accepts
OJOIFieldBasePropsbut doesn't explicitly define the shape of thegoToScreenprop. Consider creating and exporting a dedicated interface:export interface AdvertScreenProps extends OJOIFieldBaseProps { goToScreen: (screen: string) => void; }
Line range hint
12-13: Fix typo in state setter nameThe state setter has a typo:
setModalVisabilityshould besetModalVisibility- const [modalVisible, setModalVisability] = useState(false) + const [modalVisible, setModalVisibility] = useState(false)
Line range hint
15-21: Optimize timestamp generationThe
generateTimestampfunction could be moved outside the component to prevent recreation on each render. Also, consider usinguseCallbackfor the timestamp update handler:+const generateTimestamp = () => new Date().toISOString() + export const AdvertScreen = (props: OJOIFieldBaseProps) => { const { formatMessage: f } = useLocale() const [modalVisible, setModalVisability] = useState(false) - - const generateTimestamp = () => new Date().toISOString() - /** * This state here is for force rerendering of the HTML editor when a value is received from the modal */ const [timestamp, setTimestamp] = useState(generateTimestamp()) + + const handleConfirmChange = useCallback(() => { + setTimestamp(generateTimestamp()) + }, [])
Line range hint
1-9: Component follows reusability guidelinesThe component adheres to the coding guidelines for libs:
- Uses TypeScript
- Imports specific components from @island.is packages
- Component is modular and reusable
Consider adding JSDoc comments to improve documentation for reuse across different NextJS apps.
/** * Screen component for handling adverts in the Official Journal of Iceland application. * @param props - The component props extending OJOIFieldBaseProps * @returns React component for the advert screen */ export const AdvertScreen = (props: OJOIFieldBaseProps) => {libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularSignature.tsx (1)
Line range hint
14-47: Consider enhancing error handling for invalid signature types.While the implementation is solid, consider adding explicit error handling for cases where the signature type validation fails.
if (isRegularSignature(signature)) { const updatedRegularSignature = signature?.filter( (_, index) => index !== signatureIndex, ) const updatedSignatures = set( currentAnswers, InputFields.signature.regular, updatedRegularSignature, ) setValue(InputFields.signature.regular, updatedRegularSignature) updateApplication(updatedSignatures) + } else { + console.error('Invalid signature type encountered') + // Consider showing a user-friendly error message }libs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts (1)
Line range hint
1-40: Enhance type safety with TypeScript.While the implementation is functional, consider enhancing type safety by:
- Adding explicit type definitions for the message structure
- Exporting these types for consuming components
Consider adding the following type definitions:
interface OriginalMessages { general: { title: MessageDescriptor; intro: MessageDescriptor; section: MessageDescriptor; }; fileUpload: { header: MessageDescriptor; description: MessageDescriptor; buttonLabel: MessageDescriptor; }; } export const original: OriginalMessages = { // existing implementation }libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1)
Line range hint
20-47: Consider enhancing error handling and user feedbackWhile the removal logic is solid, consider these UX improvements:
- Add error handling for
updateApplication- Provide user feedback on successful/failed removal
- Add a confirmation dialog before removing members
This would make the component more robust and user-friendly.
Example implementation with confirmation:
const onRemoveMember = async () => { const confirmed = window.confirm('Are you sure you want to remove this member?') if (!confirmed) return try { const { currentAnswers, signature } = getCommitteeAnswers(application.answers) if (isCommitteeSignature(signature)) { const updatedCommitteeSignature = { ...signature, members: signature.members?.filter((_, mi) => mi !== memberIndex), } const updatedAnswers = set( currentAnswers, InputFields.signature.committee, updatedCommitteeSignature, ) setValue(InputFields.signature.committee, updatedCommitteeSignature) await updateApplication(updatedAnswers) // Add success notification here } } catch (error) { // Add error notification here console.error('Failed to remove member:', error) } }libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (1)
8-16: Consider consolidating message imports for better maintainability.The separate import of
rejectedbreaks the pattern of grouped message imports. Consider consolidating it with the other message imports.import { attachments, advert, original, requirements, preview, publishing, - } from '../lib/messages' - import { rejected } from '../lib/messages' + rejected, + } from '../lib/messages'libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularMember.tsx (1)
Line range hint
18-70: Consider generalizing the member removal componentThe component could be made more reusable by abstracting the member type-specific logic. This would allow it to be used for both regular and committee members with minimal code duplication.
Consider:
- Creating a generic
RemoveMembercomponent that accepts a member type prop- Moving the member-specific logic to a custom hook
- Sharing the removal logic between different member types
This would improve maintainability and reduce code duplication across the application.
libs/application/templates/official-journal-of-iceland/src/components/input/OJOIInputController.tsx (1)
Line range hint
75-80: Add explicit type for the event parameter.The event parameter in the onChange handler should have an explicit type for better type safety.
- onChange={(e) => + onChange={(e: React.ChangeEvent<HTMLInputElement | HTMLTextAreaElement>) => debouncedOnUpdateApplicationHandler( handleChange(e.target.value), onChange && (() => onChange(e.target.value)), ) }libs/application/templates/official-journal-of-iceland/src/lib/messages/preview.ts (2)
25-27: LGTM! Consider supporting dynamic content for better user feedback.The updated error message is more specific and clearer. However, consider making it more dynamic to list the specific missing fields.
- defaultMessage: 'Upplýsingar vantar í skráningu auglýsingar', + defaultMessage: 'Upplýsingar vantar í skráningu auglýsingar: {missingFields}',
28-31: Improve error message descriptions to be more specific.Both error messages currently share the same generic description. Consider making them more specific to help other developers understand their distinct purposes.
- description: 'Error message when content is missing', + description: 'Primary error message shown when required advertisement fields are missing',- description: 'Error message when content is missing', + description: 'Secondary message explaining the minimum required fields',libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (1)
52-52: Add JSDoc comment to document FAST_TRACK_DAYS.The constant appears to be related to the minimum weekdays (10) but lacks documentation explaining its purpose and relationship to other time constants.
+/** Number of days required for fast-track processing of applications */ export const FAST_TRACK_DAYS = 10libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (1)
Line range hint
46-57: Consider extracting department-specific logicThe special handling for department changes makes the function less reusable. Consider extracting this logic to maintain single responsibility principle.
- const handleChange = (label: string, value: string) => { + const handleDepartmentChange = (answers: any) => { + set(answers, InputFields.advert.typeId, '') + } + + const handleChange = (label: string, value: string) => { const currentAnswers = structuredClone(application.answers) const newAnswers = set(currentAnswers, name, value) if (name === InputFields.advert.departmentId) { - set(newAnswers, InputFields.advert.typeId, '') + handleDepartmentChange(newAnswers) } updateApplication(newAnswers) - onChange && onChange(label, value) + onChange?.(label, value) }libs/application/templates/official-journal-of-iceland/src/components/signatures/Committee.tsx (1)
Line range hint
56-65: Consider adding type safety to the Stack's space propThe Stack implementation looks good and improves the layout structure. However, we could enhance type safety.
Consider explicitly typing the space prop to match the design system's spacing scale:
- <Stack space={2} dividers> + <Stack space={'2'} dividers>This ensures the spacing value matches the design system's supported values.
libs/application/templates/official-journal-of-iceland/src/fields/Comments.tsx (2)
19-21: Add JSDoc documentation for the Props type.While the type definition is well-structured, adding JSDoc documentation would improve maintainability and reusability across different NextJS applications.
+/** + * Props for the Comments component + * @extends OJOIFieldBaseProps Base props for OJOI field components + * @property {boolean} [canAddComment] - Controls whether new comments can be added. Defaults to true. + */ type Props = OJOIFieldBaseProps & { canAddComment?: boolean }
80-87: Improve JSX indentation for better readability.While the conditional rendering logic is correct, the JSX indentation could be more consistent.
- {canAddComment && ( - <AddComment - addComment={addComment} - addCommentError={addCommentError} - addCommentLoading={addCommentLoading} - addCommentSuccess={addCommentSuccess} - /> - )} + {canAddComment && ( + <AddComment + addComment={addComment} + addCommentError={addCommentError} + addCommentLoading={addCommentLoading} + addCommentSuccess={addCommentSuccess} + /> + )}libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (1)
24-28: Consider adding a JSDoc comment for better documentation.The message definition is correct and reusable, but could benefit from a JSDoc comment explaining its intended usage contexts, as 'name' could refer to various entities in the application.
Add documentation above the definition:
+/** + * Generic name label used across various forms and displays + * in the Official Journal of Iceland application + */ name: { id: 'ojoi.application:general.name', defaultMessage: 'Nafn', },libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx (1)
Component has limited reusability due to tight coupling with application-specific dependencies
The component has several dependencies that limit its reusability across NextJS apps:
- Tightly coupled with
@island.isspecific packages (island-ui/core,application/core,localization)- Uses application-specific hooks (
useApplication,useLocale)- Relies on local utilities and types from the application template
- Component structure is specific to the official-journal-of-iceland template
To make it reusable:
- Extract core signature logic into a base component
- Make UI framework dependencies configurable
- Move application-specific logic to higher-order components
- Create an adapter layer for hooks and utilities
🔗 Analysis chain
Line range hint
1-89: Verify component reusability across NextJS apps.The component follows good practices for reusability, but let's verify its independence from app-specific dependencies.
Let me gather more information about the component's dependencies and their reusability.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for app-specific dependencies that might affect reusability # Test 1: Check for imports from app-specific paths rg -l "from '[^@]" libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx # Test 2: Check for dependencies on specific Next.js versions or features rg -l "next/" libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx # Test 3: Find all imports to understand dependencies rg "^import .* from" libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsxLength of output: 1152
Script:
#!/bin/bash # Check the structure and dependencies of related components fd -e tsx -e ts -e css . libs/application/templates/official-journal-of-iceland/src/components/signatures --exec rg -l "@island.is|from '\./|from '\.\." {} # Check if these components are used in other applications rg -l "RegularSignature" --type ts --type tsx # Check the island-ui/core package usage ast-grep --pattern 'import { $$$_ } from "@island.is/island-ui/core"'Length of output: 1807
libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/ChannelList.tsx (1)
Line range hint
1-92: Consider making the component more generic for better reusabilityAs this component lives in the
libs/directory, consider making it more generic to improve reusability across different NextJS applications:
- Extract OJOI-specific logic into a wrapper component
- Make the table structure configurable
- Export types for better TypeScript integration
libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1)
73-77: Consider more specific message descriptionWhile the message definition is structurally correct, the description could be more specific about the context and purpose of this message in the advertisement workflow.
message: { id: 'ojoi.application:summary.properties.message', defaultMessage: 'Skilaboð', - description: 'Message of the advertisement', + description: 'Additional message or notes associated with the advertisement submission', },libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (2)
Line range hint
37-94: Consider refactoring handleMemberChange for better maintainabilityThe function currently handles multiple responsibilities including member updates, HTML generation, and form updates. Consider breaking it down into smaller, focused functions:
+ const updateMemberField = (members: any[], memberIndex: number, key: string, value: string) => + members.map((m, i) => (i === memberIndex ? { ...m, [key]: value } : m)) + const generateUpdatedSignature = (signature: any, members: any[], additionalSignature: any) => ({ + ...signature, + members, + html: getSingleSignatureMarkup( + { ...signature, members }, + additionalSignature, + signature.chairman, + ), + }) const handleMemberChange = ( value: string, key: keyof MemberProperties, memberIndex: number, ) => { const { signature, currentAnswers } = getCommitteeAnswers(application.answers) if (!signature) return currentAnswers const additionalSignature = application.answers.signatures?.additionalSignature?.committee - const members = signature?.members?.map((m, i) => { - if (i === memberIndex) { - return { ...m, [key]: value } - } - return m - }) + const members = updateMemberField(signature.members, memberIndex, key, value) - const html = getSingleSignatureMarkup( - { ...signature, members }, - additionalSignature, - signature.chairman, - ) - const updatedCommitteeSignature = { - ...signature, - members: members, - html: html, - } + const updatedCommitteeSignature = generateUpdatedSignature( + signature, + members, + additionalSignature + ) setValue(InputFields.signature.committee, updatedCommitteeSignature) return set( currentAnswers, InputFields.signature.committee, updatedCommitteeSignature, ) }
Line range hint
96-126: Enhance form field accessibilityWhile the layout structure is good, consider adding ARIA labels and descriptions to improve accessibility for screen readers.
<SignatureMember name={`signature.committee.member.name.${memberIndex}`} label={f(signatures.inputs.name.label)} + aria-label={f(signatures.inputs.name.ariaLabel)} defaultValue={member.name} onChange={(e) => debouncedOnUpdateApplicationHandler( handleMemberChange(e.target.value, 'name', memberIndex), ) } />Please ensure that the translations include appropriate ARIA labels in the signatures messages file.
libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (1)
66-75: Enhance accessibility for name input fieldWhile the implementation is consistent with other inputs, consider adding aria-labels for better accessibility.
<Input size="xs" name="name" type="text" value={name} label={f(general.name)} + aria-label={f(general.name)} onChange={(e) => setName(e.target.value)} />libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (1)
11-17: Consider documenting the refetch prop.The new
refetchprop should be documented with JSDoc to explain its purpose and optional nature, enhancing component reusability.export const InvolvedPartyScreen = ({ application, setSubmitButtonDisabled, + /** Callback to refresh data after successful submission */ refetch, }: OJOIFieldBaseProps) => {libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (1)
81-81: Consider adding validation hint to the description.The placeholder message change provides clearer guidance about excluding the type. Consider updating the description to match this clarification.
- description: 'Placeholder for the title input', + description: 'Placeholder for the title input, indicating that type should be excluded',libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (1)
Line range hint
33-65: Consider memoizing the handleChairmanChange functionThe function is recreated on every render. Consider using useCallback to memoize it for better performance.
Here's how you can optimize it:
const handleChairmanChange = useCallback( (value: string, key: keyof MemberProperties) => { const { signature, currentAnswers } = getCommitteeAnswers( application.answers, ) // ... rest of the function }, [application.answers, setValue] )libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (1)
111-116: Enhance accessibility for the preview editor.The HTMLEditor preview should include proper ARIA attributes to improve accessibility.
<HTMLEditor name="preview.title" config={{ toolbar: false }} readOnly={true} value={titlePreview} + aria-label="Advertisement title preview" + role="region" />libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (2)
Line range hint
55-77: Add error handling and loading feedback for category updates.The category update logic should handle potential errors and provide better user feedback during updates.
Consider implementing these improvements:
const onCategoryChange = (value?: string) => { setIsUpdatingCategory(true) if (!value) { setIsUpdatingCategory(false) return } const currentAnswers = structuredClone(currentApplication.answers) const selectedCategories = currentAnswers.advert?.categories || [] const newCategories = selectedCategories.includes(value) ? selectedCategories.filter((c) => c !== value) : [...selectedCategories, value] const updatedAnswers = set( currentAnswers, InputFields.advert.categories, newCategories, ) - updateApplication(updatedAnswers, () => { - setIsUpdatingCategory(false) - }) + updateApplication(updatedAnswers) + .then(() => { + setIsUpdatingCategory(false) + }) + .catch((error) => { + // Handle error appropriately + setIsUpdatingCategory(false) + }) }
113-153: Enhance Tag component accessibility.While the error handling and loading states are well implemented, the Tag component's accessibility could be improved.
Consider these accessibility enhancements:
<Tag disabled={isUpdatingCategory} onClick={() => onCategoryChange(c.id)} outlined key={c.id} + role="button" + aria-label={`Remove ${c.title} category`} > <Box display="flex" alignItems="center"> {c.title} - <Icon icon="close" size="small" /> + <Icon + icon="close" + size="small" + aria-hidden="true" + /> </Box> </Tag>libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (2)
Line range hint
38-93: Consider extracting signature handling logic to a custom hookThe
handleMemberChangefunction contains complex state management logic that could be moved to a custom hook for better reusability and maintainability. This would also make the component more focused on rendering.Consider creating a custom hook like this:
function useSignatureMemberUpdate(applicationId: string, signatureIndex: number) { const { debouncedOnUpdateApplicationHandler, application } = useApplication({ applicationId, }); const { setValue } = useFormContext(); const updateMember = useCallback(( value: string, key: keyof MemberProperties, memberIndex: number, ) => { // Current implementation of handleMemberChange }, [application, debouncedOnUpdateApplicationHandler, setValue]); return { updateMember }; }Then simplify the component:
const { updateMember } = useSignatureMemberUpdate(applicationId, signatureIndex); // Use updateMember in onChange handlers
Line range hint
101-179: Enhance accessibility of the form layoutWhile the flexbox layout is well-structured, consider these accessibility improvements:
- Add ARIA labels to group related form fields
- Use semantic HTML elements like
fieldsetandlegendfor form sectionsConsider this enhancement:
-<Box display="flex" flexDirection="column" rowGap={2}> +<Box + display="flex" + flexDirection="column" + rowGap={2} + role="group" + aria-label={f(signatures.inputs.memberDetails)} +> {/* ... */} </Box>libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (1)
201-219: LGTM with a minor enhancement suggestion.The implementation follows the service's established patterns for API calls, error handling, and logging. Consider enriching the error log with additional context from the request parameters when available.
this.logger.warn('Failed to get application case', { error, applicationId: params.id, + params: JSON.stringify(params), category: LOG_CATEGORY, })libs/application/templates/official-journal-of-iceland/src/graphql/queries.ts (1)
307-307: Add JSDoc documentation for the query.To improve maintainability and help other developers understand the query's purpose, consider adding documentation.
Add documentation above the query:
/** * Retrieves detailed information about an application case. * @query GetApplicationCase * @param {OJOIAIdInput} input - The application case identifier * @returns {OJOIAApplicationCaseResponse} Application case details including department, type, status, and categories */libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (1)
41-43: LGTM! Consider adding input validation.The channel schema is well-structured and reusable. Consider adding email format validation and phone number pattern validation for better data integrity.
export const channelSchema = z .object({ name: z.string(), - email: z.string(), - phone: z.string(), + email: z.string().email({ message: "Invalid email format" }), + phone: z.string().regex(/^[+]?[\d\s-]+$/, { message: "Invalid phone number format" }), }) .partial()libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (2)
Line range hint
120-213: Consider extracting validation error handling to reduce duplication.The validation error handling logic is repeated three times with similar structure. Consider creating a reusable component for displaying validation errors with navigation.
Example implementation:
type ValidationErrorProps = { validationResult: SafeParseError<any>; section: string; navigateTo: Routes; goToScreen?: (route: Routes) => void; setSubmitButtonDisabled?: (disabled: boolean) => void; }; const ValidationError = ({ validationResult, section, navigateTo, goToScreen, setSubmitButtonDisabled }: ValidationErrorProps) => ( <AlertMessage type="warning" title={f(error.missingFieldsTitle, { x: section })} message={ <Stack space={2}> <BulletList color="black"> {validationResult.error.issues.map((issue) => ( <Bullet key={issue.path.join('.')}> {f(parseZodIssue(issue as ZodCustomIssue).message)} </Bullet> ))} </BulletList> <Button onClick={() => { setSubmitButtonDisabled?.(false) goToScreen?.(navigateTo) }} size="small" variant="text" preTextIcon="arrowBack" > Opna kafla {section} </Button> </Stack> } /> );🧰 Tools
🪛 Biome
[error] 133-133: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 134-134: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
269-286: Simplify communication channels rendering condition.The current condition can be simplified, and the channels array can be safely accessed using optional chaining.
<Property name={f(summary.properties.communicationChannels)} value={ - currentApplication.answers.advert?.channels?.length !== 0 && ( + currentApplication.answers.advert?.channels?.length > 0 && ( <Inline flexWrap="wrap" space={1}> - {currentApplication.answers.advert?.channels?.map( + {currentApplication.answers.advert.channels.map( (channel, i) => ( <Tag variant="blue" disabled key={i}> {channel.name} </Tag> ), )} </Inline> ) } />libs/clients/official-journal-of-iceland/application/src/clientConfig.json (2)
1031-1057: Consider adding validation constraints for the MainCategory schema.While the schema is well-structured, consider adding these validations:
- Pattern constraint for
idto ensure GUID format- MinLength/MaxLength constraints for
title,slug, anddescription"id": { "type": "string", "description": "Unique ID for the main category, GUID format.", "example": "00000000-0000-0000-0000-000000000000", - "nullable": false + "nullable": false, + "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$" }, "title": { "type": "string", "description": "Title of the main category.", - "example": "Dómstólar og réttarfar" + "example": "Dómstólar og réttarfar", + "minLength": 1, + "maxLength": 100 }
1159-1189: Consider enhancing the ApplicationCase schema documentation.The ApplicationCase schema could benefit from:
- Adding descriptions for each property
- Including examples for better API documentation
"ApplicationCase": { "type": "object", "properties": { "categories": { + "description": "List of categories associated with the application", "type": "array", "items": { "$ref": "#/components/schemas/Category" } }, "status": { + "description": "Current status of the application", "type": "object" }, "communicationStatus": { + "description": "Status of communication with the applicant", "$ref": "#/components/schemas/CommunicationStatus" }, "department": { + "description": "Department handling the application", "$ref": "#/components/schemas/Department" }, "type": { + "description": "Type of the advertisement", "$ref": "#/components/schemas/AdvertType" }, "html": { + "description": "HTML content of the advertisement", "type": "string" } }libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx (1)
52-84: SimplifycurrentAnswersconstructionInstead of using
setfrom Lodash to progressively buildcurrentAnswers, you can construct the object directly. This approach improves readability and reduces dependency on external libraries.const updateNewApplication = (id: string) => { - let currentAnswers = {} - - currentAnswers = set( - currentAnswers, - InputFields.requirements.approveExternalData, - AnswerOption.YES, - ) - - currentAnswers = set(currentAnswers, InputFields.signature.regular, [ - ...getRegularSignature( - DEFAULT_REGULAR_SIGNATURE_COUNT, - DEFAULT_REGULAR_SIGNATURE_MEMBER_COUNT, - ), - ]) - - currentAnswers = set(currentAnswers, InputFields.signature.committee, { - ...getCommitteeSignature(DEFAULT_COMMITTEE_SIGNATURE_MEMBER_COUNT), - }) + const currentAnswers = { + [InputFields.requirements.approveExternalData]: AnswerOption.YES, + [InputFields.signature.regular]: getRegularSignature( + DEFAULT_REGULAR_SIGNATURE_COUNT, + DEFAULT_REGULAR_SIGNATURE_MEMBER_COUNT, + ), + [InputFields.signature.committee]: getCommitteeSignature( + DEFAULT_COMMITTEE_SIGNATURE_MEMBER_COUNT, + ), + } updateApplicationMutation({ variables: { locale, input: { id: id, answers: currentAnswers, }, }, onCompleted: () => { navigate(`/${slug}/${id}`) }, + onError: (error) => { + console.error('Failed to update application:', error) + }, }) }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (65)
- apps/web/screens/OfficialJournalOfIceland/OJOISearch.tsx (0 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.resolver.ts (2 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.service.ts (2 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts (1 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/ChannelList.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/htmlEditor/HTMLEditor.css.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/input/OJOIInputController.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Additional.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Committee.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularMember.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularSignature.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Signatures.css.ts (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (6 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Comments.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/CommunicationChannels.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (5 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (9 hunks)
- libs/application/templates/official-journal-of-iceland/src/forms/Complete.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/graphql/queries.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts (11 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (5 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/attachments.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/error.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/index.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/involved-parties.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/preview.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/publishing.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/submitted.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/types.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/utils.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/AdvertScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/CommentsScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/OriginalScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/SummaryScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/index.ts (1 hunks)
- libs/clients/official-journal-of-iceland/application/src/clientConfig.json (4 hunks)
- libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (2 hunks)
💤 Files with no reviewable changes (1)
- apps/web/screens/OfficialJournalOfIceland/OJOISearch.tsx
🧰 Additional context used
📓 Path-based instructions (64)
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.resolver.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.service.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/ChannelList.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/htmlEditor/HTMLEditor.css.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/input/OJOIInputController.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Additional.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Committee.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularSignature.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Signatures.css.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Comments.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/CommunicationChannels.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/forms/Complete.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/graphql/queries.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/attachments.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/error.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/index.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/involved-parties.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/preview.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/publishing.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/submitted.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/types.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/utils.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/AdvertScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/CommentsScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/OriginalScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/SummaryScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/index.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/clients/official-journal-of-iceland/application/src/clientConfig.json (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
🪛 Biome
libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx
[error] 57-57: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx
[error] 105-105: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 144-144: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx
[error] 133-133: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 134-134: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 173-173: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 174-174: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 204-204: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 205-205: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts
[error] 92-92: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx
[error] 26-26: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 54-54: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 104-104: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (88)
libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts (1)
1-9: LGTM! Well-structured GraphQL input type.The implementation follows NestJS and GraphQL best practices with proper decorators and type definitions.
libs/application/templates/official-journal-of-iceland/src/screens/index.ts (1)
11-11: LGTM! Export follows best practices.The new export for
RejectScreenfollows the established pattern, maintaining consistency with other screen exports. The barrel file structure supports effective tree-shaking and module reusability across NextJS apps.libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts (1)
20-22: Consider adding sanitization for HTML content.The
htmlfield might need sanitization to prevent XSS attacks if this content is rendered in the UI.Let's check if there are any HTML sanitization utilities in use:
libs/application/templates/official-journal-of-iceland/src/lib/messages/index.ts (1)
15-15: Verify the existence of the rejected module.The addition of this export aligns with the PR objective of adding a "Rejected" state. However, let's verify that the module exists to prevent potential runtime errors.
✅ Verification successful
Export statement is valid and module exists
The verification confirms that
rejected.tsexists at the correct location:libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts. The export statement is valid and follows the established pattern.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence of the rejected module # Expected: The rejected.ts or rejected/index.ts file should exist in the same directory fd -t f "rejected.(ts|tsx)" "$(dirname $(rg -l 'export \* from ./rejected' -g '*.ts'))"Length of output: 265
Script:
#!/bin/bash # Let's try a different approach to verify the existence of the rejected module # First, find the exact location of the index.ts file rg --files-with-matches "export \* from './rejected'" # Then search for rejected.ts or rejected/index.ts in the repository fd -t f "rejected\.(ts|tsx)$" libs/application/templates/official-journal-of-iceland/src/lib/messages/Length of output: 409
libs/application/templates/official-journal-of-iceland/src/screens/OriginalScreen.tsx (2)
Line range hint
1-16: LGTM! Component follows best practicesThe component is well-structured, reusable, and follows TypeScript practices. It properly uses shared components and localization hooks, making it maintainable across different NextJS applications.
13-13: Verify type definition ofgoToScreenPlease ensure that
goToScreenis properly typed in theOJOIFieldBasePropsinterface.✅ Verification successful
goToScreenis properly typed in the component hierarchyThe verification shows that
goToScreenis correctly typed throughout the codebase:
FormScreencomponent defines it in its props:goToScreen?: (screen: string) => voidOJOIFieldBasePropsinherits fromFieldBasePropswhich includes the navigation props- The prop is consistently used across multiple screen components and fields
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the type definition of OJOIFieldBaseProps # Expected: Should find the type definition including goToScreen # Search for OJOIFieldBaseProps type definition ast-grep --pattern 'interface OJOIFieldBaseProps { $$$ }' # Alternatively, search using ripgrep rg -A 10 'interface OJOIFieldBaseProps'Length of output: 103
Script:
#!/bin/bash # Let's try a broader search to find the interface definition # First, let's find all TypeScript files in the official-journal-of-iceland directory fd -e ts -e tsx . libs/application/templates/official-journal-of-iceland # Then search for any interface or type definitions related to props rg -A 10 "type.*Props|interface.*Props" libs/application/templates/official-journal-of-iceland # Also search for goToScreen usage to understand its context rg "goToScreen" libs/application/templates/official-journal-of-icelandLength of output: 65949
libs/application/templates/official-journal-of-iceland/src/screens/SummaryScreen.tsx (2)
11-13: LGTM! Well-structured prop handling.The changes maintain proper TypeScript typing and follow component reusability best practices. The addition of
goToScreenprop enhances navigation capabilities while keeping the component focused and maintainable.
5-5: Verify localization namespace change across the codebase.The change from
publishingtosummarynamespace should be consistent across all components using these messages.✅ Verification successful
Import change is part of a new feature, not a namespace reorganization
The search results show that both
publishingandsummarynamespaces coexist and serve different purposes:
publishingnamespace is used in PublishingScreen with messages about publication preferencessummarynamespace is used in SummaryScreen with messages about submission confirmationThis is not a namespace reorganization but rather separate features with their own localization messages. The import change is correct and consistent with the codebase structure.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining usage of the old 'publishing' namespace # and verify the existence of the new 'summary' namespace in messages # Test 1: Search for any remaining references to the old namespace echo "Checking for remaining 'publishing' namespace usage:" rg "publishing\.general\.(title|intro)" -A 2 # Test 2: Verify the existence and structure of the new namespace echo -e "\nVerifying 'summary' namespace structure:" rg "summary\.general\.(title|intro)" -A 2Length of output: 3163
libs/application/templates/official-journal-of-iceland/src/screens/CommentsScreen.tsx (2)
Line range hint
1-17: LGTM! Clean and maintainable implementationThe changes follow best practices:
- Reusable component structure
- Proper TypeScript usage
- Clean imports for effective tree-shaking
14-14: Verify type definition of goToScreen propLet's ensure type safety by verifying the type definition of
goToScreenin the base props interface.✅ Verification successful
goToScreen prop is properly typed and used consistently
Based on the codebase analysis:
- The
goToScreenprop is consistently typed as(id: string) => voidacross multiple componentsOJOIFieldBasePropsextendsFieldBasePropswhich includes this prop type- The
FormScreencomponent correctly handles the prop, using it only in development mode for navigation- The implementation matches the usage pattern across the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for OJOIFieldBaseProps definition to verify goToScreen type ast-grep --pattern 'interface OJOIFieldBaseProps { $$$ goToScreen$_ $$$ }'Length of output: 82
Script:
#!/bin/bash # Let's try a broader search for the interface definition rg -A 10 "interface OJOIFieldBaseProps" # Also search for FormScreen component props to understand the type requirements ast-grep --pattern 'interface FormScreenProps { $$$ }' # Search for actual usage of FormScreen to understand the prop pattern rg "FormScreen" -A 5Length of output: 40351
Script:
#!/bin/bash # Let's check the OJOIFieldBaseProps interface definition rg "interface OJOIFieldBaseProps" -A 10 libs/application/templates/official-journal-of-iceland/src/lib/types.ts # Also check FormScreen component props in the same template rg "interface FormScreenProps" -A 10 libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsxLength of output: 242
Script:
#!/bin/bash # Let's try searching for type definitions in the entire codebase rg "type OJOIFieldBaseProps" -A 5 # Also search for the FormScreen component's usage pattern rg "FormScreen.*goToScreen" -B 2 -A 2 # Check FormScreen component's implementation ast-grep --pattern 'export const FormScreen = ({ $$$, goToScreen, $$$ }: $_) => { $$$ }'Length of output: 12875
Script:
#!/bin/bash # Let's check the FieldBaseProps type that OJOIFieldBaseProps extends rg "type FieldBaseProps" -A 10 # Also check if goToScreen is used in other components to understand its type pattern rg "goToScreen: \(.*\) =>" -A 2Length of output: 1162
libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx (2)
Line range hint
1-24: LGTM! Changes follow best practices.The addition of
goToScreenprop maintains component reusability and follows proper TypeScript patterns. The component remains tree-shakeable with specific imports and named exports.
20-20: Verify type safety of the goToScreen prop.Let's ensure the type definition is properly handled.
✅ Verification successful
Type safety of goToScreen prop is verified
The
goToScreenprop is properly typed and handled throughout the codebase:
- In
FormScreen.tsx, it's defined as an optional prop with correct type:type Props = { goToScreen?: (screen: string) => void }
In
OJOIFieldBaseProps, it inherits the type fromFieldBasePropswhich is imported from@island.is/application/typesThe prop is consistently used across all screens in the application with proper type safety
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify type definitions for goToScreen prop # Expected: Find type definition in OJOIFieldBaseProps and FormScreen props # Check OJOIFieldBaseProps type definition ast-grep --pattern 'type OJOIFieldBaseProps = { $$$ goToScreen$_ $$$ }' # Check FormScreen component props ast-grep --pattern 'interface $_Props { $$$ goToScreen$_ $$$ }'Length of output: 151
Script:
#!/bin/bash # Let's try a different approach to find type definitions and usages # Find the file content to understand the context cat libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx # Search for FormScreen component definition and its props rg "FormScreen" -A 5 -B 5 # Search for any type definitions containing goToScreen rg "goToScreen" -A 2 -B 2Length of output: 242607
Script:
#!/bin/bash # Let's check the FormScreen component definition and OJOIFieldBaseProps type cat libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx cat libs/application/templates/official-journal-of-iceland/src/lib/types.tsLength of output: 5814
libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx (1)
11-11: LGTM! Verify consistent prop usage across screens.The addition of the
goToScreenprop follows TypeScript best practices and maintains component reusability.Let's verify consistent prop usage across other screens:
Also applies to: 19-19
libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (1)
6-21: Verify uniqueness of message IDs.Let's ensure these new message IDs don't conflict with existing ones.
✅ Verification successful
Message IDs are unique across the codebase
The verification results show that each message ID appears exactly once in the codebase, confirming there are no duplicates:
ojoi.application:rejected.general.title: 1 occurrenceojoi.application:rejected.general.intro: 1 occurrenceojoi.application:rejected.general.section: 1 occurrenceojoi.application:rejected.general.goToServicePortal: 1 occurrence🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for duplicate message IDs across the application # Search for any duplicate occurrences of the new message IDs echo "Checking for duplicate message IDs..." for id in "ojoi.application:rejected.general.title" \ "ojoi.application:rejected.general.intro" \ "ojoi.application:rejected.general.section" \ "ojoi.application:rejected.general.goToServicePortal"; do echo "Checking ID: $id" rg -l "$id" | wc -l doneLength of output: 1594
libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1)
15-15: LGTM! Clean implementation of screen navigation.The addition of the
goToScreenprop follows the consistent pattern used across other screen components, maintaining good reusability and type safety.libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts (2)
1-2: LGTM! Clean imports following best practices.The named imports support effective tree-shaking.
19-32: Verify consistent error handling across hook usage.Let's ensure consistent error handling patterns across components using this hook.
✅ Verification successful
Error handling is appropriately implemented in the component
The review comment's concern about error handling can be resolved based on the following findings:
- The
Submittedcomponent appropriately handles the loading state usingSkeletonLoadercomponents- The component only uses loading and caseData from the hook, which is sufficient since:
- It's a read-only display component
- Error scenarios would result in empty data display, which is handled gracefully
- The component provides fallback UI during loading states
- The hook follows Apollo Client's standard error handling pattern by returning the error object
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for components using this hook and verify error handling patterns rg -A 5 "useApplicationCase" --type ts --type tsxLength of output: 77
Script:
#!/bin/bash # Search for components using this hook with ripgrep, without file type restrictions rg -A 5 "useApplicationCase" # Also search for the query constant to understand its usage rg "GET_APPLICATION_CASE_QUERY"Length of output: 2587
Script:
#!/bin/bash # Let's examine the Submitted component to see how it handles loading and errors cat libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx # Also check the query definition to understand the response structure cat libs/application/templates/official-journal-of-iceland/src/graphql/queries.tsLength of output: 11035
libs/application/templates/official-journal-of-iceland/src/components/signatures/Additional.tsx (2)
Line range hint
1-19: LGTM! Component structure follows best practices.The component demonstrates good practices with:
- Strong TypeScript typing
- Proper use of shared UI components
- Effective localization implementation
- Clear prop definitions
Line range hint
20-24: Verify the layout changes align with design requirements.The removal of
display="flex"andjustifyContent="flexStart"properties from the Box component might affect the layout. Please confirm this change aligns with the UI updates mentioned in the PR objectives.Let's check for any related style definitions:
libs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (2)
18-20: LGTM: Message references updated consistently.The message references have been updated consistently to use the new 'original' namespace, maintaining proper localization practices.
25-25: Verify the impact of disabling multiple file uploads.Adding
multiple={false}is a potentially breaking change if the component previously allowed multiple files.Let's check for existing file upload patterns:
libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts (2)
8-8: LGTM! Well-typed callback parameter.The optional
onCompletedcallback is properly typed with the correct response type.
27-27: LGTM! Clean parameter destructuring.The
onCompletedparameter is correctly added to the hook's parameters, maintaining consistency with the type definition.libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1)
1-7: LGTM! Imports follow best practicesThe imports are well-structured, using named imports that support effective tree-shaking and bundling.
libs/application/templates/official-journal-of-iceland/src/lib/messages/submitted.tsx (1)
15-19: LGTM! Verify message usage across components.The new message entry follows the established patterns and integrates well with the existing structure. The ID is properly namespaced, and the description is clear.
Let's verify the usage of this new message key:
✅ Verification successful
✓ Message is properly integrated and used
The message is correctly used in
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsxand follows the established i18n patterns. The message key is also properly imported in related components through the messages file.
- Used in:
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx- Imported in:
SubmittedScreen.tsx,Submitted.tsx, andSubmitted.ts- No hardcoded instances of the text were found that should be using this message instead
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check where the new message is being used # Expected: Components using this message for the new application button # Search for components using this specific message key rg "newApplication" --type ts --type tsx # Search for any hardcoded occurrences of the text that should use this message rg -i "Ný umsókn" --type ts --type tsxLength of output: 137
Script:
#!/bin/bash # Let's try without file type filters since ripgrep doesn't recognize tsx # Search for components using this specific message key rg "newApplication" # Search for any hardcoded occurrences of the text rg -i "Ný umsókn" # Also search for potential imports of the messages file rg -l "from.*messages/submitted"Length of output: 18665
libs/application/templates/official-journal-of-iceland/src/forms/Complete.ts (3)
1-1: LGTM! Good job on import optimization.The cleanup of unused imports and specific import of only required functions improves tree-shaking capabilities.
Line range hint
24-59: Verify if empty section children arrays are intentional.All form sections have empty children arrays (
children: []). This might indicate missing form fields or incomplete implementation.Let's check if this is intentional by looking for field definitions in other files:
Line range hint
1-59: Verify the impact of removed imports.The AI summary indicates that
buildCustomField,buildMultiField, andsummaryimports were removed. Let's verify that these aren't needed anymore.libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularSignature.tsx (2)
Line range hint
1-8: LGTM! Well-structured imports and type definitions.The code follows best practices:
- Proper TypeScript usage for props definition
- Specific imports enabling effective tree-shaking
- Reusable components from shared UI library
Also applies to: 9-12
49-58: LGTM! Clean and maintainable UI structure.The Box wrapper with flex properties provides better layout control while maintaining component reusability.
libs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts (2)
25-26: LGTM: File upload messages are more user-friendly.The changes to the file upload messages improve clarity by:
- Providing more specific instructions about accepted document types (scanned copies or digitally signed)
- Simplifying the file format message
- Using a more concise button label
The message structure maintains consistency with
react-intlpatterns.Let's verify the component usage:
Also applies to: 31-31, 36-36
✅ Verification successful
File upload messages are consistently used across components
The search results confirm that the file upload messages in
libs/application/templates/official-journal-of-iceland/src/lib/messages/original.tsare properly referenced in the corresponding components:
- The messages are used in
Original.tsxandAttachments.tsxcomponents with the correct message keys- The message structure follows the standard pattern used across other templates in the codebase
- The file upload functionality is implemented consistently with other similar features
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of these messages in components # to ensure all implementations are updated echo "Searching for components using these messages..." ast-grep --pattern 'fileUpload.header' --lang typescript ast-grep --pattern 'fileUpload.description' --lang typescript ast-grep --pattern 'fileUpload.buttonLabel' --lang typescriptLength of output: 287
Script:
#!/bin/bash # Let's try a broader search with ripgrep to find usages of these messages echo "Searching for fileUpload message usages..." rg -l "fileUpload" --type ts # Then let's examine the content of any files that might use these messages echo -e "\nSearching for specific message keys..." rg "fileUpload\." --type ts -A 2 -B 2Length of output: 122522
7-7: Verify the terminology change impact across the application.The terminology change from "Frumgögn" to "Frumrit" in both title and section messages should be consistent across the entire application to maintain a unified user experience.
Let's verify the terminology usage:
Also applies to: 18-18
✅ Verification successful
Based on the search results, I can now make a determination about the terminology change:
The terminology change is consistent across the codebase
The search results show that:
- The old term "Frumgögn" is not found anywhere in the codebase
- The new term "Frumrit" appears consistently in the relevant locations:
- In the message definition (
defaultMessage: 'Frumrit')- In the constants file (
ORIGINAL = 'frumrit')- In the UI components where it's being used
The change appears to be a proper terminology update that has been consistently applied across all necessary parts of the application, maintaining a unified user experience.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for any remaining instances of old terminology # to ensure consistent updates across the codebase echo "Searching for potential inconsistencies in terminology..." rg -i "Frumgögn" --type ts --type tsx echo "Verifying the new terminology usage..." rg -i "Frumrit" --type ts --type tsxLength of output: 352
Script:
#!/bin/bash # Let's try a different approach without file type restrictions # Search for both terms in all files, focusing on the application directory echo "Searching for the old terminology..." rg -i "Frumgögn" ./libs/application echo "Searching for the new terminology..." rg -i "Frumrit" ./libs/application # Also search for message definitions that might be related echo "Searching for related message definitions..." rg "defineMessages|defaultMessage.*Frum" ./libs/applicationLength of output: 217672
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1)
Line range hint
9-13: Well-structured TypeScript implementation!The component follows TypeScript best practices with proper type definitions and interfaces. The use of scoped packages and specific imports supports effective tree-shaking.
Also applies to: 15-18
libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (1)
24-53: Verify the purpose of empty sections.Multiple sections (Requirements, Advert, Attachments, Preview, Original, Publishing) are defined but contain no children. Please confirm if this is intentional or if these sections need to be implemented.
✅ Verification successful
Based on the search results, I can see that these sections are implemented differently across various form states:
- In
Draft.tsandDraftRetry.ts, these sections have children with custom fields- In
Requirements.ts, only the REQUIREMENTS section has children while others are empty- In
Rejected.ts,Complete.ts, andSubmitted.ts, all sections are intentionally emptySince this code is in
Rejected.ts, it appears to be intentional to have empty sections as it represents a rejected state where the form should be read-only or display-only.Empty sections are intentional in the rejected state
The empty sections in the rejected form state align with the pattern seen in other final states (Complete, Submitted) where sections are intentionally kept empty, likely to show a read-only view of the form structure.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any existing implementations of these sections in other form files rg -A 5 "Routes\.(REQUIREMENTS|ADVERT|ATTACHMENTS|PREVIEW|ORIGINAL|PUBLISHING)" --type tsLength of output: 29130
libs/application/templates/official-journal-of-iceland/src/lib/messages/involved-parties.ts (2)
13-13: LGTM! Message update aligns with PR objectives.The updated message better reflects the user's context by acknowledging access to multiple legal entities and clarifying the purpose of selection for advertisement submission.
13-13: Verify message usage consistency.Let's ensure this message change is reflected consistently across all components using this translation key.
✅ Verification successful
No consistency issues found with the message
The message appears to be used only once in the codebase, specifically in
libs/application/templates/official-journal-of-iceland/src/lib/messages/involved-parties.ts. There are no other instances where this exact message or similar variations are used, indicating that this is a localized message specific to this component.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for components using this specific message key to verify consistency # Search for usage of the intro message key rg -l "ojoi\.application:original\.general\.intro" --type ts --type tsx # Search for any hardcoded text that might need updating rg -i "veldu stofnun|veldu þann" --type ts --type tsxLength of output: 185
Script:
#!/bin/bash # Search for the message text in all files rg -i "Þú hefur aðgang að fleiri en einum lögaðila" # Search for similar message patterns rg -i "veldu" # List all TypeScript files in the involved-parties related components fd "involved-parties" -e tsLength of output: 51034
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularMember.tsx (1)
Line range hint
10-17: Well-structured TypeScript implementationThe component demonstrates good TypeScript practices with properly typed props and clear interface definition.
libs/application/templates/official-journal-of-iceland/src/components/input/OJOIInputController.tsx (1)
Line range hint
1-89: LGTM! Well-structured component with good practices.The component follows good practices:
- Proper TypeScript usage for props and types
- Efficient imports supporting tree-shaking
- Good separation of concerns
- Proper state management
- Handles i18n correctly
- Uses shared components for reusability
libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (1)
39-39: LGTM: New rejected route added.The addition of the
REJECTEDroute aligns with the PR objective of introducing a rejected state for applications.libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (2)
81-81: LGTM: Clean implementation of onSelect handlerThe implementation properly passes both label and value to the handler, maintaining type safety and following TypeScript best practices.
24-24: Breaking Change: Verify impact of onChange signature updateThe onChange prop signature has been updated to include both label and value. Since this component is in the libs directory and could be used across different applications, we should verify all existing usages.
✅ Verification successful
Let me gather more specific information about the usage of OJOISelectController component to understand the impact better.
Let me check one more thing to see how the component is being used in InvolvedPartyScreen.tsx for a complete verification.
Breaking change in onChange handler is already compatible
Based on the codebase analysis, the change to include the label parameter in onChange is safe:
- In Advert.tsx, there are multiple usages:
- One usage already implements the new signature with
(label, value)parameters- Another usage uses
(_, value)pattern, explicitly ignoring the label parameter- In InvolvedPartyScreen.tsx, there's no direct onChange handler usage
- No other usages found in the codebase
The existing implementations are already compatible with the new signature, making this a non-breaking change.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for all usages of OJOISelectController to verify onChange handler compatibility rg -l "OJOISelectController" | xargs rg "onChange"Length of output: 990
Script:
#!/bin/bash # Get the implementation context of OJOISelectController usage in Advert.tsx rg -B 5 -A 5 "OJOISelectController" libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx # Also check for any imports and type definitions ast-grep --pattern 'import { $$ } from "$_"' libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsxLength of output: 2069
Script:
#!/bin/bash # Get the implementation context of OJOISelectController usage in InvolvedPartyScreen.tsx rg -B 5 -A 5 "OJOISelectController" libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsxLength of output: 1131
libs/application/templates/official-journal-of-iceland/src/components/signatures/Committee.tsx (2)
1-1: LGTM: Import changes and coding guidelines complianceThe addition of the Stack component from the shared UI library follows the coding guidelines by:
- Using the organization's design system components
- Maintaining proper TypeScript typing
- Supporting effective tree-shaking through specific imports
Line range hint
1-74: Well-structured and reusable component implementationThe component demonstrates excellent practices:
- Clear separation of concerns
- Proper use of shared hooks and utilities
- Strong TypeScript typing
- Reusable design that can be used across different NextJS applications
libs/application/templates/official-journal-of-iceland/src/lib/types.ts (2)
Line range hint
1-116: Well-structured types and exports!The file demonstrates excellent TypeScript practices with:
- Clear type definitions enabling reuse across different NextJS apps
- Proper exports supporting effective tree-shaking
- Generic type utilities enhancing maintainability
15-15: LGTM! Consider documenting requirement status.The addition of
typeNamefollows the established pattern and maintains type safety. However, it's worth clarifying if this field should be required for adverts.Let's check if this field is used as a required field in other parts of the codebase:
✅ Verification successful
typeNameis correctly implemented as an optional fieldBased on the codebase analysis:
- The
typeNamefield is used inOJOIApplication.tsfor application naming purposes- In
dataSchema.ts, it's defined as optional in theadvertSchema- No validation requirements are enforced for this field in any validation schemas
- It's used alongside
titleto generate application names, with fallback handling when either is missing🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check usage of typeName in validation schemas or required field lists rg -g '*.ts' -g '*.tsx' -A 5 'typeName.*required|required.*typeName'Length of output: 70
Script:
#!/bin/bash # Let's try a broader search to understand the usage of typeName in the codebase rg -g '*.ts' -g '*.tsx' "advert\.typeName" # Also search for validation schemas or required fields patterns in the same directory fd -e ts -e tsx . libs/application/templates/official-journal-of-iceland/src/lib/ --exec rg -l "RequiredInputFieldsNames|required|validation"Length of output: 782
Script:
#!/bin/bash # Let's check the validation logic in dataSchema.ts and how typeName is used in OJOIApplication.ts cat libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts # Also check the context where typeName is used in OJOIApplication.ts cat libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.tsLength of output: 17790
libs/application/templates/official-journal-of-iceland/src/lib/messages/attachments.ts (1)
38-39: LGTM! Clear upload instructions addedThe enhanced description now clearly explains the file selection process and ordering requirements, improving the user experience.
libs/application/templates/official-journal-of-iceland/src/fields/Comments.tsx (1)
23-23: LGTM! Well-structured component signature.The component signature is properly typed and includes a sensible default value for the optional prop.
libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (2)
12-15: LGTM! Message definition follows best practices.The message definition is well-structured and follows the established patterns:
- Proper namespacing with 'ojoi.application:general.*'
- Consistent with the existing i18n structure
- Enables effective tree-shaking through named exports
16-19: LGTM! Status label aligns with PR objectives.The message definition properly supports the new application states mentioned in the PR objectives, particularly for tracking submitted applications.
libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx (1)
59-72: LGTM! Improved layout structure using Stack component.The Stack component from island-ui provides better layout management with consistent spacing and dividers between members. This change aligns with the design system and improves maintainability.
libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1)
68-72: LGTM: Well-structured message definition for communication channelsThe property follows the established pattern and maintains consistency with other message definitions. The description accurately reflects the purpose of the message.
libs/application/templates/official-journal-of-iceland/src/components/signatures/Signatures.css.ts (3)
3-3: LGTM! Good use of constants.The import of
OJOI_INPUT_HEIGHTfrom constants promotes reusability and maintainability across the application.
63-63: LGTM! Improved layout structure.The column direction provides better vertical alignment for form inputs, which is more intuitive for signature-related fields.
112-118: LGTM! Consistent styling with design system.The styling follows the design system with:
- Consistent border and border-radius using theme values
- Proper dimensions using the shared constant
- Well-structured flex layout for centering content
libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts (2)
5-6: LGTM: Proper type imports and shared package usage.The new imports follow TypeScript best practices and utilize shared types from the @island.is packages, promoting reusability across applications.
Also applies to: 13-14
38-38: LGTM: Well-structured mutation hooks with proper typing.The mutation hooks follow Apollo Client patterns and include proper loading and error states. The rename to
updateApplicationMutationimproves code clarity.Also applies to: 42-47
libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (1)
Line range hint
1-126: Implementation follows best practices and guidelinesThe component implementation:
- Uses TypeScript effectively with proper type definitions
- Follows reusability principles with modular design
- Uses specific imports enabling effective tree-shaking
- Maintains consistent layout patterns with island-ui components
libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx (1)
30-30: LGTM! Well-typed optional propThe
goToScreenprop is properly typed as an optional function parameter, making the component more flexible and reusable.libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (1)
13-13: LGTM: Props type definition is well-structuredThe new
defaultNameprop follows TypeScript best practices and maintains consistency with existing prop definitions.libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (1)
Line range hint
1-110: Implementation approved with minor suggestions.The component maintains good practices for reusability, TypeScript usage, and proper tree-shaking. The new functionality is well-integrated with existing code patterns.
🧰 Tools
🪛 Biome
[error] 104-104: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (2)
32-32: LGTM! Message update looks good.The message change maintains consistency with Icelandic language conventions.
Line range hint
1-105: Well-structured messages module!The file demonstrates good practices:
- Clear organization of messages by UI section
- Proper use of TypeScript with react-intl
- Maintainable and reusable structure
libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (2)
Line range hint
17-21: Well-structured TypeScript implementation!The component demonstrates good TypeScript practices with proper type definitions and Zod schema validation.
Line range hint
80-119: Improved layout structure using flexbox!The new layout implementation using flex properties provides better organization and responsiveness.
libs/application/templates/official-journal-of-iceland/src/lib/messages/publishing.ts (2)
44-54: LGTM! Well-structured message definitions for fast track publishing.The new message definitions follow the established patterns and best practices:
- Proper namespacing of message IDs
- Clear descriptions that aid translators
- Consistent structure with other message definitions
96-96: LGTM! More concise placeholder text.The updated placeholder text is more direct and clearer about the message recipient.
libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (1)
24-28: LGTM! Clean hook implementation.The useApplication hook usage is well-structured with proper TypeScript typing and follows React best practices.
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.resolver.ts (1)
28-29: LGTM! Clean imports following TypeScript practices.The imports are specific and well-named, supporting effective tree-shaking.
libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (2)
10-10: LGTM: Clean state management implementation.The new state variables and imports are well-organized and follow React best practices.
Also applies to: 19-20, 24-24, 51-53
155-161: LGTM: Well-implemented alert message.The fastTrack alert message is properly implemented with localization and follows the design system guidelines.
libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (2)
Line range hint
15-23: Well-structured TypeScript implementation!The component demonstrates good TypeScript practices with proper type definitions for props and schema validation using zod.
Line range hint
1-179: Compliant with coding guidelinesThe implementation successfully meets the requirements for:
- ✓ Component reusability
- ✓ TypeScript usage
- ✓ Tree-shaking optimization
libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (2)
19-20: LGTM! Import changes follow best practices.The new type imports maintain consistency with existing patterns and support effective tree-shaking.
Line range hint
1-219: Confirms compliance with coding guidelines.The implementation adheres to all required guidelines for
libs/**/*:
- ✓ Reusable across NextJS apps (injectable, framework-agnostic)
- ✓ Strong TypeScript usage (proper typing, clear interfaces)
- ✓ Effective tree-shaking support (named imports, no side effects)
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.service.ts (1)
26-26: LGTM!The import statement follows the established pattern and TypeScript best practices.
libs/application/templates/official-journal-of-iceland/src/lib/utils.ts (2)
16-16: LGTM!The import statement follows the proper convention and is correctly grouped with related constants.
325-344: Verify the usage of getFastTrack and FAST_TRACK_DAYS.Let's ensure consistent usage across the codebase.
✅ Verification successful
Implementation of getFastTrack and FAST_TRACK_DAYS is consistent across the codebase
The verification shows:
FAST_TRACK_DAYSis properly defined as a constant (10 days) inconstants.tsand correctly imported inutils.tsgetFastTrackis used consistently in two components:
Summary.tsx: For displaying fast track statusPublishing.tsx: For handling date selection and fast track updates🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of getFastTrack and FAST_TRACK_DAYS # Test 1: Check getFastTrack usage echo "Checking getFastTrack usage:" rg "getFastTrack" -A 3 # Test 2: Verify FAST_TRACK_DAYS constant definition and usage echo -e "\nChecking FAST_TRACK_DAYS constant:" rg "FAST_TRACK_DAYS" -A 1Length of output: 3571
libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (2)
50-50: LGTM! Type name field added correctly.The optional typeName field is properly integrated into the advertSchema.
Line range hint
238-257: LGTM! Improved error handling.Good improvement to accumulate all validation errors instead of returning early. This provides a better user experience by showing all validation issues at once.
libs/application/templates/official-journal-of-iceland/src/lib/messages/error.ts (2)
67-67: LGTM: Improved message clarity.The changes to signature-related messages enhance readability while maintaining their semantic meaning.
Also applies to: 77-77
107-107: LGTM: Consistent terminology update.The terminology change from "submissions" to "advertisements" is applied consistently and aligns with the PR objectives for UI improvements.
Also applies to: 112-112, 117-117, 122-122
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (1)
7-10: LGTM: Props and imports are well structured.The new imports and prop additions follow TypeScript best practices and maintain component reusability.
Also applies to: 17-18, 36-36
libs/application/templates/official-journal-of-iceland/src/components/htmlEditor/HTMLEditor.css.ts (2)
Line range hint
1-1000: Well-structured and maintainable CSS-in-TS implementation.The implementation follows best practices for library code:
- Uses vanilla-extract for type-safe CSS-in-TS
- Implements modular and reusable styles
- Follows effective tree-shaking practices
142-142: Verify the reduced editor height's impact on usability.The minimum height reduction from 200px to 100px is acceptable, but please ensure this change doesn't negatively impact the editor's usability, especially for longer content.
Let's check if this editor component is used in other places:
✅ Verification successful
The previous command failed due to unsupported file type flag. Let's try a broader search to find any references to the HTMLEditor component and its imports across the codebase.
Let's examine how the HTMLEditor is actually used in these field components to better understand if the height reduction might impact specific use cases.
Height reduction is safe for this component's usage
The reduced minimum height (100px) is appropriate as all instances of HTMLEditor in the codebase are used in read-only mode for preview/display purposes. These use cases include:
- Document submission view (read-only)
- Preview view (read-only)
- Advertisement title preview (read-only with no toolbar)
- Signature preview (read-only)
Since there are no editing use cases found and all instances are for preview/display purposes, the smaller minimum height won't impact usability and allows for more compact layouts.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find usages of the HTMLEditor component to assess the impact of height change rg -l "HTMLEditor" --type ts --type tsxLength of output: 67
Script:
#!/bin/bash # Search for HTMLEditor component usage with ripgrep, without file type filtering rg -l "HTMLEditor" # Also search for potential imports of this component rg "import.*HTMLEditor"Length of output: 1466
Script:
#!/bin/bash # Let's check the actual usage context in these files to understand how the editor height might affect them rg -A 5 "<HTMLEditor" libs/application/templates/official-journal-of-iceland/src/fields/Length of output: 2780
libs/clients/official-journal-of-iceland/application/src/clientConfig.json (2)
300-324: LGTM: Well-structured endpoint definition.The new endpoint
/api/v1/applications/{id}/casefollows the RESTful conventions and maintains consistency with other endpoints in the API. The response schema is properly referenced.
792-795: LGTM: Clear addition of internal comment flag.The new
internalboolean property in the CaseComment schema is well-documented and properly marked as required, which aligns with the PR's objective of improving application state management.Also applies to: 835-835
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (1)
32-32: EnsuregoToScreenis properly typed inOJOIFieldBasePropsVerify that the
goToScreenprop is included and correctly typed in theOJOIFieldBasePropsinterface to maintain type safety.libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts (1)
67-67: Verify that thenameproperty accepts a functionEnsure that the
nameproperty in theApplicationTemplatesupports a function that returns a string. If it expects a static string, using a function may lead to unexpected behavior.
libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts
Show resolved
Hide resolved
libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts
Show resolved
Hide resolved
libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 44
🧹 Outside diff range and nitpick comments (52)
libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts (1)
3-9: LGTM! Consider enhancing documentation.The implementation is well-structured and type-safe. Consider these documentation improvements:
- Add more context to the InputType description (e.g., "Input DTO that represents the ID of the Official Journal of Iceland application")
- Add a @field description for the
idfieldApply this diff to enhance the documentation:
@InputType('OJOIAIdInput', { - description: 'Input dto that represents the id of the application', + description: 'Input DTO that represents the ID of the Official Journal of Iceland application', }) export class OJOIAIdInput { - @Field(() => ID) + @Field(() => ID, { + description: 'Unique identifier of the Official Journal of Iceland application' + }) id!: string }libs/application/templates/official-journal-of-iceland/src/screens/index.ts (1)
Line range hint
1-11: Consider using named exports for better tree-shaking.The current use of
export *can potentially impact tree-shaking as it re-exports everything from each module. Consider using named exports to explicitly declare which components should be available.Example refactor:
-export * from './AdvertScreen' -export * from './AttachmentsScreen' -export * from './OriginalScreen' -export * from './RequirementsScreen' -export * from './PreviewScreen' -export * from './PublishingScreen' -export * from './SummaryScreen' -export * from './SubmittedScreen' -export * from './CommentsScreen' -export * from './InvolvedPartyScreen' -export * from './RejectScreen' +export { AdvertScreen } from './AdvertScreen' +export { AttachmentsScreen } from './AttachmentsScreen' +export { OriginalScreen } from './OriginalScreen' +export { RequirementsScreen } from './RequirementsScreen' +export { PreviewScreen } from './PreviewScreen' +export { PublishingScreen } from './PublishingScreen' +export { SummaryScreen } from './SummaryScreen' +export { SubmittedScreen } from './SubmittedScreen' +export { CommentsScreen } from './CommentsScreen' +export { InvolvedPartyScreen } from './InvolvedPartyScreen' +export { RejectScreen } from './RejectScreen'libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts (2)
3-4: Add class documentation.Consider adding JSDoc documentation to describe the purpose and usage of this response type.
+/** + * Response type for Official Journal of Iceland application cases. + * Contains details about the application's department, type, status, and content. + */ @ObjectType('OJOIAApplicationCaseResponse') export class OJOIAApplicationCaseResponse {
17-22: Add field documentation.Consider adding descriptions to the GraphQL fields to improve API documentation.
+ /** Categories associated with the application case */ @Field(() => [String]) categories!: string[] + /** HTML content of the application case */ @Field() html!: stringlibs/application/templates/official-journal-of-iceland/src/screens/OriginalScreen.tsx (1)
Line range hint
1-16: Consider documenting navigation flow.Since this is part of a broader navigation enhancement across multiple screens, it would be helpful to document the expected navigation flow in comments or types.
Add JSDoc comments to describe the navigation behavior:
+/** + * Screen component for the original document submission. + * Allows navigation between screens using the goToScreen prop. + */ export const OriginalScreen = (props: OJOIFieldBaseProps) => {libs/application/templates/official-journal-of-iceland/src/screens/CommentsScreen.tsx (1)
14-14: Consider making the goToScreen prop type more visible.The implementation looks good and aligns with the navigation improvements. However, for better type visibility and maintainability, consider explicitly defining the
goToScreenprop type in the component's props interface.-export const CommentsScreen = (props: OJOIFieldBaseProps) => { +interface CommentsScreenProps extends OJOIFieldBaseProps { + goToScreen: (screen: string) => void; +} + +export const CommentsScreen = (props: CommentsScreenProps) => {libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx (1)
Line range hint
7-7: Consider extending type definition for better prop documentation.Since
goToScreenis a significant navigation prop, it would be helpful to explicitly document its type inOJOIFieldBaseProps.interface OJOIFieldBaseProps { // ... existing props goToScreen: (screen: string) => void; // Add explicit type for navigation function }libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (2)
1-1: Consider adding TypeScript types for better type safety.To align with the coding guidelines for TypeScript usage, consider importing and using the
MessageDescriptortype from 'react-intl'.-import { defineMessages } from 'react-intl' +import { defineMessages, MessageDescriptor } from 'react-intl'
3-23: Add type definitions for better maintainability.The message structure looks good and follows proper i18n practices. Consider adding TypeScript types to improve type safety and maintainability.
+type RejectedMessages = { + general: { + [K in 'title' | 'intro' | 'section' | 'goToServicePortal']: MessageDescriptor + } +} -export const rejected = { +export const rejected: RejectedMessages = { general: defineMessages({ // ... existing messages }), }libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1)
Line range hint
18-20: Consider explicit prop passing for better maintainabilityInstead of spreading props to child components, consider passing only the required props explicitly. This makes the component contract clearer and helps with type safety.
- <Publishing {...props} /> - <CommunicationChannels {...props} /> - <Message {...props} /> + <Publishing goToScreen={props.goToScreen} /* other required props */ /> + <CommunicationChannels goToScreen={props.goToScreen} /* other required props */ /> + <Message goToScreen={props.goToScreen} /* other required props */ />libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx (2)
6-6: Consider documenting supported value types.Since the value prop now accepts ReactNode, it would be helpful to add JSDoc comments specifying which types of nodes are supported and providing usage examples.
type Props = { name?: string + /** Value to display. Supports string or simple React elements. + * @example + * value="Simple string" + * value={<span>Formatted text</span>} + */ value?: string | React.ReactNode loading?: boolean }
Line range hint
1-35: Consider enhancing component reusability.The component follows good practices for reusability, but could be improved:
- Consider extracting styles to a theme-based system for better customization
- Add prop for customizing the Text component variant
- Consider making the layout structure more flexible
This would enhance its reusability across different NextJS apps as per the coding guidelines.
libs/application/templates/official-journal-of-iceland/src/components/signatures/Additional.tsx (2)
Line range hint
7-10: Consider enhancing Props interface for better reusability.The current Props interface is minimal. Consider adding optional props for better component flexibility:
classNamefor custom stylingtestIdfor testing purposesonSignatureChangecallback for parent componentstype Props = { applicationId: string name: string + className?: string + testId?: string + onSignatureChange?: (value: string) => void }
Line range hint
1-2: Improve tree-shaking with specific imports.The Box and Text components are imported from the root package. Consider using more specific imports to improve tree-shaking.
-import { Box, Text } from '@island.is/island-ui/core' +import { Box } from '@island.is/island-ui/core/Box' +import { Text } from '@island.is/island-ui/core/Text'libs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (1)
Line range hint
1-33: Component structure promotes reusabilityThe component demonstrates good practices for library code:
- Proper TypeScript usage with explicit prop types
- Leverages shared UI components and hooks
- Clean separation of concerns between UI and file handling logic
Consider adding prop documentation using JSDoc to improve component discoverability and usage guidance across different apps.
libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1)
8-10: Consider adding component documentation and explicit return type.While the component is well-structured, consider these improvements for better maintainability:
+/** + * RejectScreen component displays the rejection state of an application + * with comments and a navigation button to the service portal. + */ -export const RejectScreen = (props: OJOIFieldBaseProps) => { +export const RejectScreen = (props: OJOIFieldBaseProps): JSX.Element => {libs/application/templates/official-journal-of-iceland/src/screens/AdvertScreen.tsx (3)
Line range hint
4-4: Enhance type safety for props and callbacksThe
goToScreenprop should have an explicit type definition. Additionally, consider avoiding prop spreading without type safety.Apply this improvement:
- goToScreen={props.goToScreen} + goToScreen: (screen: string) => void = props.goToScreenAlso applies to: 23-23
Line range hint
12-17: Extract modal and timestamp logic into a custom hookConsider extracting the modal visibility and timestamp management into a reusable hook to improve maintainability and testing.
Example implementation:
const useAdvertModal = (onConfirm?: () => void) => { const [modalVisible, setModalVisibility] = useState(false); const [timestamp, setTimestamp] = useState(() => new Date().toISOString()); const handleConfirm = () => { setTimestamp(new Date().toISOString()); onConfirm?.(); }; return { modalVisible, setModalVisibility, timestamp, handleConfirm }; };
Line range hint
12-16: Fix typo and optimize state managementThere are several improvements needed:
- "setModalVisability" has a typo (should be "setModalVisibility")
generateTimestampshould be memoized or moved outside the component- Consider using a more precise timestamp format
Apply these fixes:
- const [modalVisible, setModalVisability] = useState(false) + const [modalVisible, setModalVisibility] = useState(false) - const generateTimestamp = () => new Date().toISOString() - const [timestamp, setTimestamp] = useState(generateTimestamp()) + const [timestamp, setTimestamp] = useState(() => new Date().toISOString())libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1)
Line range hint
1-1: Optimize imports for better tree-shaking.Consider destructuring specific components from the UI library to potentially reduce bundle size.
-import { Box, Button } from '@island.is/island-ui/core' +import Box from '@island.is/island-ui/core/Box' +import Button from '@island.is/island-ui/core/Button'libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (2)
1-16: Consider consolidating message importsThe
rejectedmessage import could be included in the destructured import with other messages to maintain consistency and reduce the number of import statements.import { attachments, advert, original, requirements, preview, publishing, + rejected, } from '../lib/messages' -import { rejected } from '../lib/messages'
17-23: Consider making the form ID more specificThe current ID 'OfficialJournalOfIcelandAdvertOfIcelandApplication' doesn't indicate that this is specifically for the rejected state. Consider appending 'Rejected' to make it more explicit.
- id: 'OfficialJournalOfIcelandAdvertOfIcelandApplication', + id: 'OfficialJournalOfIcelandAdvertOfIcelandApplicationRejected',libs/application/templates/official-journal-of-iceland/src/components/input/OJOIInputController.tsx (1)
Line range hint
9-21: Addrequiredto Props interfaceThe Props interface should include the
requiredproperty to make the field's validation state configurable by parent components.type Props = { name: string label: string | MessageDescriptor placeholder?: string | MessageDescriptor defaultValue?: string loading?: boolean applicationId: string disabled?: boolean textarea?: boolean onChange?: (value: string) => void + required?: boolean }libs/application/templates/official-journal-of-iceland/src/lib/messages/preview.ts (2)
25-31: Consider adding TypeScript types for better type safety.The message changes look good and provide clearer error feedback. However, consider adding TypeScript types to improve type safety and maintainability.
Add types at the beginning of the file:
type MessageDescriptor = { id: string; defaultMessage: string; description: string; }; type PreviewMessages = { general: Record<string, MessageDescriptor>; errors: Record<string, MessageDescriptor>; buttons: Record<string, MessageDescriptor>; }; export const preview: PreviewMessages = { // ... existing code };
30-31: Enhance the description field for better context.The description field could be more specific about when this message is shown and what constitutes "minimum" content.
- description: 'Error message when content is missing', + description: 'Error message indicating minimum required fields must be filled in the advertisement registration form',libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (1)
52-52: Add JSDoc comment to document FAST_TRACK_DAYS purposeConsider adding documentation to explain the significance of the 10-day period and its relationship with
MINIMUM_WEEKDAYS.+/** Number of days for fast-track processing of applications */ export const FAST_TRACK_DAYS = 10libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (2)
Line range hint
46-56: Consider extracting department-specific logic.The special handling for department changes creates tight coupling. Consider extracting this logic into a separate hook or utility function for better maintainability and reusability.
// Create a custom hook const useAnswerUpdate = (applicationId: string) => { const { updateApplication, application } = useApplication({ applicationId }) return useCallback((field: string, value: string) => { const newAnswers = structuredClone(application.answers) set(newAnswers, field, value) if (field === InputFields.advert.departmentId) { set(newAnswers, InputFields.advert.typeId, '') } updateApplication(newAnswers) }, [application, updateApplication]) }
57-57: Use optional chaining for better readability.Replace the && operator with optional chaining for better readability and maintainability.
- onChange && onChange(label, value) + onChange?.(label, value)🧰 Tools
🪛 Biome
[error] 57-57: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (1)
24-28: Remove extra empty line for consistent spacingWhile the message definition is correct, consider removing the empty line after the
namemessage block to maintain consistent spacing with other message blocks in the file.name: { id: 'ojoi.application:general.name', defaultMessage: 'Nafn', }, - phoneNumber: {libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1)
Line range hint
1-87: Consider adding TypeScript types for better type safety.Since this file is in the
libs/directory, it should prioritize type safety for reusability across NextJS apps. Consider adding explicit TypeScript types for the exported messages.Here's how you could improve type safety:
type MessageDescriptor = { id: string; defaultMessage: string; description: string; }; type SummaryMessages = { general: { title: MessageDescriptor; intro: MessageDescriptor; section: MessageDescriptor; }; properties: { sender: MessageDescriptor; type: MessageDescriptor; // ... other properties communicationChannels: MessageDescriptor; message: MessageDescriptor; fastTrackYes: MessageDescriptor; fastTrackNo: MessageDescriptor; }; }; export const summary: SummaryMessages = { // ... existing implementation };libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts (1)
81-95: Optimize callback handling and improve type safety.The implementation is good but can be improved in a few ways:
- Use optional chaining as suggested by static analysis
- Add return type annotation for better type safety
Apply these improvements:
const createApplication = async ( onComplete?: (data: { createApplication: Application }) => void, -) => { +): Promise<void> => { await createApplicationMutation({ variables: { input: { typeId: ApplicationTypes.OFFICIAL_JOURNAL_OF_ICELAND, initialQuery: null, }, }, onCompleted: (data) => { - onComplete && onComplete(data) + onComplete?.(data) }, }) }🧰 Tools
🪛 Biome
[error] 92-92: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (2)
Line range hint
26-94: Consider refactoring state management for better maintainability.The
handleMemberChangefunction handles multiple responsibilities including state updates, HTML generation, and form management. This could be simplified for better maintainability and testing.Consider splitting the functionality:
// Separate member update logic const updateMember = (members: Member[], index: number, key: string, value: string) => members.map((m, i) => i === index ? { ...m, [key]: value } : m); // Separate HTML generation const generateSignatureHtml = (signature: Signature, additional: Additional, chairman: Chairman) => getSingleSignatureMarkup(signature, additional, chairman); // Simplified handler const handleMemberChange = ( value: string, key: keyof MemberProperties, memberIndex: number, ) => { const { signature, currentAnswers } = getCommitteeAnswers(application.answers); if (!signature) return currentAnswers; const updatedMembers = updateMember(signature.members, memberIndex, key, value); const html = generateSignatureHtml( { ...signature, members: updatedMembers }, application.answers.signatures?.additionalSignature?.committee, signature.chairman, ); const updatedSignature = { ...signature, members: updatedMembers, html, }; setValue(InputFields.signature.committee, updatedSignature); return set(currentAnswers, InputFields.signature.committee, updatedSignature); };
Line range hint
107-126: Consider using theme-based spacing for columnGap.While the flex layout is good, using a numeric value for columnGap might not align with the design system's spacing scale.
Consider using the spacing prop from the theme:
-<Box display="flex" columnGap={2}> +<Box display="flex" columnGap="gutter"}>libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx (1)
Line range hint
33-43: Consider architectural improvements for better maintainability.
- Extract the development navigation into a separate component:
const DevNavigation: React.FC<{ goToScreen: Props['goToScreen'] }> = ({ goToScreen }) => { if (process.env.NODE_ENV !== 'development' || !goToScreen) return null; // ... navigation buttons };
- Consider using React.memo for performance optimization if the component re-renders frequently with the same props:
export const FormScreen = React.memo(({ ... }) => { // ... component logic });libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (1)
66-75: Enhance accessibility for the name input fieldWhile the implementation is consistent with other inputs, consider adding ARIA attributes and input validation feedback.
<Input size="xs" name="name" type="text" value={name} label={f(general.name)} onChange={(e) => setName(e.target.value)} + aria-required="true" + hasError={name.trim().length === 0} + errorMessage={name.trim().length === 0 ? f(general.required) : undefined} />libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (2)
11-18: Add type definition for the refetch prop.The
refetchprop should be properly typed for better type safety and documentation.export const InvolvedPartyScreen = ({ application, setSubmitButtonDisabled, - refetch, + refetch?: () => void, }: OJOIFieldBaseProps) => {
103-105: Use optional chaining in onChange handler.For consistency with TypeScript best practices, use optional chaining for the callback.
onChange={() => { - setSubmitButtonDisabled && setSubmitButtonDisabled(false) + setSubmitButtonDisabled?.setSubmitButtonDisabled(false) }}🧰 Tools
🪛 Biome
[error] 104-104: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (2)
Line range hint
1-39: Consider renaming the component for better reusabilityThe component name "Chairman" is tightly coupled to a specific role. Consider a more generic name like
SignatureFormMemberorCommitteeMemberSignatureto improve reusability across different contexts where similar signature functionality might be needed.-export const Chairman = ({ applicationId, member }: Props) => { +export const CommitteeMemberSignature = ({ applicationId, member }: Props) => {
Line range hint
18-24: Enhance TypeScript type definitionsConsider the following TypeScript improvements:
- Export the
MemberPropertiestype for reuse in other components- Use more specific event types in onChange handlers
-type MemberProperties = ReturnType<typeof getEmptyMember> +export type MemberProperties = ReturnType<typeof getEmptyMember> type Props = { applicationId: string member?: z.infer<typeof memberItemSchema> }And for the onChange handlers:
-onChange={(e) => +onChange={(e: React.ChangeEvent<HTMLInputElement>) =>libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (2)
110-117: LGTM: Clean preview implementation.The HTMLEditor preview is well-implemented. Consider adding an aria-label for better accessibility.
<HTMLEditor name="preview.title" config={{ toolbar: false }} readOnly={true} + aria-label="Advertisement title preview" value={titlePreview} />
Line range hint
1-143: Well-structured component with good TypeScript usage.The component follows best practices for reusability and type safety. The state management is clean, and the UI updates are properly handled. The implementation aligns well with the PR objectives of improving the Official Journal of Iceland application.
Consider extracting the preview logic into a separate hook for better reusability across the application.
libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (1)
10-10: LGTM! Consider adding type annotations for state variables.The new imports and state management additions look good and align with the component's enhanced functionality.
Consider adding explicit type annotations for better type safety:
- const [isUpdatingCategory, setIsUpdatingCategory] = useState(false) + const [isUpdatingCategory, setIsUpdatingCategory] = useState<boolean>(false) - const [fastTrack, setFastTrack] = useState(getFastTrack(new Date(defaultDate)).fastTrack) + const [fastTrack, setFastTrack] = useState<boolean>(getFastTrack(new Date(defaultDate)).fastTrack)Also applies to: 19-20, 24-24, 51-53
libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (3)
Line range hint
101-179: Consider extracting common layout patterns into reusable componentsThe Box layout structure works well but could be more reusable across different NextJS apps. Consider creating a dedicated layout component for this signature pattern.
Example implementation:
// SignatureLayout.tsx interface SignatureLayoutProps { above: React.ReactNode; nameAndAfter: React.ReactNode[]; below: React.ReactNode; actions: React.ReactNode; } export const SignatureLayout: React.FC<SignatureLayoutProps> = ({ above, nameAndAfter, below, actions }) => ( <Box display="flex" flexDirection="column" rowGap={2}> <Box>{above}</Box> <Box display="flex" columnGap={2} rowGap={2} flexWrap="wrap"> {nameAndAfter.map((item, index) => ( <Box key={index} flexGrow={1}> {item} </Box> ))} </Box> <Box display="flex" columnGap={2}> <Box flexGrow={1}>{below}</Box> {actions} </Box> </Box> );
Line range hint
37-82: Consider breaking down handleMemberChange for better maintainabilityThe function handles multiple responsibilities: form updates, signature HTML generation, and state management. Consider splitting it into smaller, focused functions.
Example refactor:
const updateMemberField = (members: Member[], memberIndex: number, key: keyof MemberProperties, value: string) => members.map((member, index) => index === memberIndex ? { ...member, [key]: value } : member ); const updateSignature = (signature: Signature, signatureIndex: number, updatedMembers: Member[]) => { const additionalSignature = application.answers.signatures?.additionalSignature?.regular; const html = getSingleSignatureMarkup( { ...signature, members: updatedMembers }, additionalSignature ); return { ...signature, html, members: updatedMembers }; }; const handleMemberChange = ( value: string, key: keyof MemberProperties, si: number, mi: number, ) => { const { signature, currentAnswers } = getRegularAnswers(application.answers); if (!signature) return currentAnswers; const updatedRegularSignature = signature.map((s, index) => index === si ? updateSignature(s, index, updateMemberField(s.members, mi, key, value)) : s ); setValue(InputFields.signature.regular, updatedRegularSignature); return set(currentAnswers, InputFields.signature.regular, updatedRegularSignature); };
Line range hint
16-27: Enhance type safety with more specific typesConsider strengthening the TypeScript definitions for better type safety and documentation.
Example improvements:
type MemberField = 'above' | 'name' | 'after' | 'below'; interface Member { above: string; name: string; after: string; below: string; } type Props = { applicationId: string; signatureIndex: number; memberIndex: number; member?: Member; } const handleMemberChange = ( value: string, key: MemberField, signatureIndex: number, memberIndex: number, ) => { // ... implementation };Also applies to: 37-37
libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (1)
202-219: LGTM: Implementation follows service patterns.The method maintains consistency with existing patterns for auth, error handling, and logging.
Consider adding JSDoc documentation to describe the method's purpose and parameters:
/** * Retrieves an application case by its ID * @param params - The request parameters containing the application case ID * @param auth - Authentication context * @returns Promise resolving to the application case details * @throws Error if the API request fails */ async getApplicationCase(libs/application/templates/official-journal-of-iceland/src/graphql/queries.ts (2)
307-318: Consider adding TypeScript type definitions for the response.While the query implementation is correct, adding explicit TypeScript types for the response would improve type safety and developer experience.
Add a type definition for the response:
export interface ApplicationCaseResponse { department: string; type: string; status: string; communicationStatus: string; categories: string[]; html: string; } export interface GetApplicationCaseData { OJOIAGetApplicationCase: ApplicationCaseResponse; }
307-307: Add documentation for the query purpose and usage.To improve maintainability and help other developers understand the query's purpose, consider adding JSDoc documentation.
Add documentation above the query:
/** * Retrieves detailed information about an application case. * @remarks * This query is used to fetch the current state and content of an application case, * including its department, type, status, and rendered HTML content. */libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (1)
Line range hint
238-257: Consider a more functional approach to validation.While the current implementation correctly validates both fields before returning, it could be more concise using a functional approach:
const validateInstitutionAndDate = ( institution: string | undefined, date: string | undefined, context: z.RefinementCtx, ) => { - let success = true - if (!institution) { - context.addIssue({ - code: z.ZodIssueCode.custom, - params: error.missingSignatureInstitution, - }) - success = false - } - - if (!date) { - context.addIssue({ - code: z.ZodIssueCode.custom, - params: error.missingSignatureDate, - }) - success = false - } - - return success + const validations = [ + { + isValid: !!institution, + error: error.missingSignatureInstitution + }, + { + isValid: !!date, + error: error.missingSignatureDate + } + ]; + + validations.forEach(({ isValid, error }) => { + if (!isValid) { + context.addIssue({ + code: z.ZodIssueCode.custom, + params: error + }); + } + }); + + return validations.every(({ isValid }) => isValid); }libs/application/templates/official-journal-of-iceland/src/lib/messages/error.ts (1)
85-104: Consider enhancing preview error messages for better user guidance.While the preview error messages are clear, they could be more descriptive to better guide users. Consider adding action-oriented messages.
Apply this diff to improve user guidance:
missingPreviewType: { id: 'ojoi.application:error.missingPreviewType', - defaultMessage: 'Tegund auglýsingar', + defaultMessage: 'Vinsamlegast veldu tegund auglýsingar', description: 'Error message when type is missing', }, missingPreviewDepartment: { id: 'ojoi.application:error.missingPreviewDepartment', - defaultMessage: 'Deild', + defaultMessage: 'Vinsamlegast veldu deild', description: 'Error message when department is missing', }, missingPreviewTitle: { id: 'ojoi.application:error.missingPreviewTitle', - defaultMessage: 'Heiti auglýsingar', + defaultMessage: 'Vinsamlegast fylltu út heiti auglýsingar', description: 'Error message when title is missing', }, missingPreviewHtml: { id: 'ojoi.application:error.missingPreviewHtml', - defaultMessage: 'Meginmál auglýsingar', + defaultMessage: 'Vinsamlegast fylltu út meginmál auglýsingar', description: 'Error message when html is missing', },libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (1)
35-37: Consider improving TypeScript type safety for the goToScreen prop.The
goToScreenprop should be properly typed to ensure type safety when navigating between routes.+type GoToScreenFn = (route: Routes) => void; export const Summary = ({ application, setSubmitButtonDisabled, - goToScreen, + goToScreen?: GoToScreenFn, }: OJOIFieldBaseProps) => {libs/clients/official-journal-of-iceland/application/src/clientConfig.json (1)
792-795: Consider documenting the impact of the 'internal' flag.While the boolean flag is properly typed, its implications on comment visibility or handling should be documented in the description.
"internal": { "type": "boolean", - "description": "Is the comment internal." + "description": "When true, indicates that the comment is for internal use only and should not be visible to external users." },Also applies to: 835-835
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (65)
- apps/web/screens/OfficialJournalOfIceland/OJOISearch.tsx (0 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.resolver.ts (2 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.service.ts (2 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts (1 hunks)
- libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/ChannelList.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/htmlEditor/HTMLEditor.css.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/input/OJOIInputController.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Additional.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Committee.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularMember.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularSignature.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/components/signatures/Signatures.css.ts (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (6 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Comments.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/CommunicationChannels.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (5 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (9 hunks)
- libs/application/templates/official-journal-of-iceland/src/forms/Complete.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/graphql/queries.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts (11 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (5 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/attachments.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/error.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/index.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/involved-parties.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/preview.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/publishing.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/submitted.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/types.ts (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/utils.ts (2 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/AdvertScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/CommentsScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (3 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/OriginalScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/SummaryScreen.tsx (1 hunks)
- libs/application/templates/official-journal-of-iceland/src/screens/index.ts (1 hunks)
- libs/clients/official-journal-of-iceland/application/src/clientConfig.json (4 hunks)
- libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (2 hunks)
💤 Files with no reviewable changes (1)
- apps/web/screens/OfficialJournalOfIceland/OJOISearch.tsx
🧰 Additional context used
📓 Path-based instructions (64)
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.resolver.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.service.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/ChannelList.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/htmlEditor/HTMLEditor.css.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/input/OJOIInputController.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Additional.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Committee.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularMember.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularSignature.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/components/signatures/Signatures.css.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Comments.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/CommunicationChannels.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/forms/Complete.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/graphql/queries.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/attachments.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/error.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/index.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/involved-parties.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/preview.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/publishing.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/submitted.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/types.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/utils.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/AdvertScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/CommentsScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/OriginalScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/SummaryScreen.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/screens/index.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/clients/official-journal-of-iceland/application/src/clientConfig.json (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
🪛 Biome
libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx
[error] 57-57: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx
[error] 105-105: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 144-144: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx
[error] 133-133: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 134-134: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 173-173: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 174-174: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 204-204: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 205-205: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts
[error] 92-92: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx
[error] 26-26: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 54-54: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 104-104: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (116)
libs/api/domains/official-journal-of-iceland-application/src/models/id.input.ts (1)
1-1: LGTM! Imports are well-structured.The imports are specific and support effective tree-shaking.
libs/application/templates/official-journal-of-iceland/src/screens/index.ts (1)
11-11: LGTM! Export added for the new Reject state feature.The new export aligns with the PR objective of adding a "Rejected state" feature and follows the existing pattern of screen exports.
libs/application/templates/official-journal-of-iceland/src/lib/messages/index.ts (1)
15-15: LGTM! Verify the rejected.ts file exists.The new export follows the established barrel pattern and maintains consistency with other message exports.
Let's verify the existence of the rejected.ts file:
✅ Verification successful
Export statement is valid - rejected.ts file exists
The verification confirms that the rejected.ts file exists at the expected location:
libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the rejected.ts file exists in the messages directory # Expected: File should exist in the same directory as index.ts fd -t f "rejected.ts" -p "libs/application/templates/official-journal-of-iceland/src/lib/messages"Length of output: 180
libs/application/templates/official-journal-of-iceland/src/screens/OriginalScreen.tsx (1)
13-13: LGTM! Verify type definitions.The addition of
goToScreenprop follows the consistent prop-passing pattern. However, let's verify the type definitions are properly set up.✅ Verification successful
Based on the search results, I can now provide a definitive response about the
goToScreenprop usage:Type definition and consistent usage verified
The
FormScreencomponent's Props type definition inlibs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsxproperly includes thegoToScreenprop:type Props = { ... goToScreen?: (screen: string) => void }The prop is consistently passed through all screen components in the official-journal-of-iceland template:
- AttachmentsScreen
- AdvertScreen
- CommentsScreen
- OriginalScreen
- PreviewScreen
- PublishingScreen
- SummaryScreen
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify FormScreen Props type includes goToScreen and check consistency across screens # Test 1: Check FormScreen Props type definition ast-grep --pattern 'type Props = { $$$ goToScreen$_ $$$ }' # Test 2: Check consistent implementation across screens rg -A 2 "FormScreen" --type typescriptLength of output: 140
Script:
#!/bin/bash # Let's try different approaches to verify the type definitions and usage # Check FormScreen type definitions and props rg -t tsx -t ts "type Props.*=.*{" -A 10 "FormScreen" # Check goToScreen usage across screens rg -t tsx -t ts "goToScreen" libs/application/templates/official-journal-of-iceland/src/screens/ # Find all screen components in the template fd -e tsx -e ts "Screen.tsx$" libs/application/templates/official-journal-of-iceland/src/screens/Length of output: 1329
Script:
#!/bin/bash # Let's fix the regex and file type issues # Check FormScreen type definitions and props rg "type Props" -A 10 --type-add 'tsx:*.tsx' --type tsx # Check goToScreen usage across screens rg "goToScreen" --type-add 'tsx:*.tsx' --type tsx libs/application/templates/official-journal-of-iceland/src/screens/ # Check FormScreen component usage rg "FormScreen" --type-add 'tsx:*.tsx' --type tsx libs/application/templates/official-journal-of-iceland/src/screens/Length of output: 124283
libs/application/templates/official-journal-of-iceland/src/screens/SummaryScreen.tsx (2)
5-5: LGTM: Import statement is correctly updatedThe change from
publishingtosummarymessages is consistent and follows proper import practices.
11-13: Props updates look good, verify goToScreen implementationThe changes to title and intro props are consistent, and the goToScreen prop is correctly forwarded. Let's verify the implementation of this navigation prop across the codebase.
✅ Verification successful
Let me gather more information about the navigation-related props and their usage.
goToScreen prop implementation is correctly typed and used
The verification confirms that:
goToScreenis properly defined in the baseFieldBasePropsinterface as an optional prop with type(id: string) => void- The prop is inherited by
OJOIFieldBasePropsthrough theOverrideutility type- The implementation in SummaryScreen follows the correct typing and prop forwarding pattern
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consistent implementation of goToScreen prop # across all screen components in the official-journal-of-iceland template # Search for screen components using goToScreen prop ast-grep --pattern 'const $screen = ($props: OJOIFieldBaseProps) => { $$$ goToScreen={$_} $$$ }' # Search for the OJOIFieldBaseProps type definition to verify goToScreen is properly typed rg -A 5 "type OJOIFieldBaseProps"Length of output: 698
Script:
#!/bin/bash # Search for FieldBaseProps type definition to check if goToScreen is defined there rg -A 10 "type FieldBaseProps" # Search for goToScreen prop usage in screen components rg -A 2 "goToScreen={" --type typescript # Search for goToScreen type or interface definitions ast-grep --pattern "interface $_ { $$$ goToScreen: $_ $$$ }"Length of output: 254
Script:
#!/bin/bash # Search for goToScreen prop usage with fixed regex rg "goToScreen=\{" --type typescript # Search for FieldBaseProps definition in node_modules rg "export (type|interface) FieldBaseProps" -A 10 # Search for screen components that might use goToScreen ast-grep --pattern 'const $screen = ($props: $_Props) => { $$$ }'Length of output: 978
libs/application/templates/official-journal-of-iceland/src/screens/CommentsScreen.tsx (1)
14-14: Verify consistent navigation implementation.Let's verify that the
goToScreenprop is consistently implemented across other screens as mentioned in the summary.✅ Verification successful
goToScreenprop implementation is consistent with one minor variationThe
goToScreenprop is consistently implemented across all screen components, with most screens usingprops.goToScreen. There is one minor variation in AttachmentsScreen.tsx which usesgoToScreendirectly instead ofprops.goToScreen, but this is likely due to prop destructuring in the component parameters.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if goToScreen prop is consistently implemented across screen components # Expected: Find goToScreen prop usage in AttachmentsScreen, OriginalScreen, PreviewScreen, and PublishingScreen # Search for screen components using goToScreen prop ast-grep --pattern 'FormScreen $$$goToScreen={$_}$$$' # Alternatively, search for all screen components to compare fd -e tsx --full-path "Screen.tsx$" --exec rg -l "FormScreen"Length of output: 1240
Script:
#!/bin/bash # Let's check the implementation of goToScreen prop in these screen components rg -U "goToScreen={.*?}" ./libs/application/templates/official-journal-of-iceland/src/screens/*.tsxLength of output: 1114
Script:
#!/bin/bash # Let's check the implementation of goToScreen prop in these screen components with fixed regex rg "goToScreen=" ./libs/application/templates/official-journal-of-iceland/src/screens/*.tsx -A 1Length of output: 2570
libs/application/templates/official-journal-of-iceland/src/screens/PreviewScreen.tsx (1)
20-20: LGTM! Verify consistent prop usage across screens.The addition of
goToScreenprop follows the established pattern and integrates well with the navigation system.Let's verify the consistent usage of
goToScreenacross other screen components:✅ Verification successful
goToScreenprop usage is consistent across screensThe verification shows that
goToScreenprop is consistently passed through toFormScreencomponent across all screen components in the OJOI application, with the same patterngoToScreen={props.goToScreen}(except for AttachmentsScreen which uses a destructured version). This confirms that the implementation in PreviewScreen follows the established pattern correctly.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if goToScreen prop is consistently used across screen components # Expected: All screen components should handle goToScreen prop similarly ast-grep --pattern 'export const $screen = ($props: $_) => { $$$ return ( <FormScreen $$$ goToScreen={$props.goToScreen} $$$ > }'Length of output: 161
Script:
#!/bin/bash # Let's try a different approach to find FormScreen usage with goToScreen prop # First, let's find all screen components in the OJOI directory rg -l "FormScreen" libs/application/templates/official-journal-of-iceland/src/screens/ # Then check the goToScreen prop usage pattern rg "goToScreen={" libs/application/templates/official-journal-of-iceland/src/screens/ -A 1 -B 1Length of output: 1227
Script:
#!/bin/bash # Let's check the goToScreen prop usage with fixed regex rg "goToScreen=" libs/application/templates/official-journal-of-iceland/src/screens/ -A 1 -B 1 # Also check the prop type definitions rg "type.*Props.*=.*{" libs/application/templates/official-journal-of-iceland/src/screens/ -A 5Length of output: 2667
libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx (3)
Line range hint
1-24: LGTM! Compliant with coding guidelinesThe component follows the required guidelines for libs/**/* files:
- ✓ Reusable component structure
- ✓ TypeScript for props and types
- ✓ Proper import/export for effective tree-shaking
19-19: LGTM! Verify consistent navigation implementationThe
goToScreenprop is correctly passed to the FormScreen component, enhancing navigation capabilities.✅ Verification successful
Navigation implementation verified as consistent
The
goToScreenprop is correctly implemented in the AttachmentsScreen component:
- It's properly typed as part of
OJOIFieldBaseProps- It's correctly passed down to the
FormScreencomponent- The implementation follows the common pattern seen across the codebase where
goToScreenis defined as(id: string) => void- The prop is used consistently for navigation purposes in review screens and form components
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consistent implementation of goToScreen across screens # Expected: All screen components should handle navigation similarly # Search for similar screen components using goToScreen ast-grep --pattern 'export const $_Screen = ({ $$$, goToScreen }: $_Props) => { $$$ return ( <FormScreen $$$ goToScreen={goToScreen} $$$ > }'Length of output: 173
Script:
#!/bin/bash # Let's try a different approach to verify navigation implementation # Search for goToScreen prop usage rg "goToScreen={" -A 2 -B 2 # Search for goToScreen type definitions rg "goToScreen.*:" -A 1 -B 1 # Search for FormScreen component implementation ast-grep --pattern 'const FormScreen = ({ $$$, goToScreen, $$$ }: $_Props) => { $$$ }'Length of output: 19608
Script:
#!/bin/bash # Let's try one more search to find goToScreen usage in the specific component # Search for FormScreen component usage with goToScreen rg "goToScreen={goToScreen}" -A 2 -B 2 # Search for the specific file's content cat "libs/application/templates/official-journal-of-iceland/src/screens/AttachmentsScreen.tsx"Length of output: 920
11-11: Verify type definition for goToScreen propPlease ensure that the
goToScreenprop is properly typed in theOJOIFieldBasePropsinterface to maintain type safety.libs/application/templates/official-journal-of-iceland/src/lib/messages/rejected.ts (1)
3-23: Verify message usage in UI components.Let's verify how these rejection messages are being used in the UI components.
✅ Verification successful
Let me check the actual usage of these messages in the components found.
Messages are properly integrated and used in the application
The rejection messages are correctly used across the codebase:
RejectScreen.tsxproperly imports and uses all message keys (title, intro, goToServicePortal)Rejected.tsform correctly uses the section message for the rejection section- All message keys defined in
rejected.tsare being utilized in the UI components🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usage of these messages in UI components echo "Searching for message usage..." rg -l "rejected\.general\." libs/application/templates/official-journal-of-iceland/ # Search for other rejection-related components echo "Searching for rejection-related components..." fd -e tsx -e ts "Reject" libs/application/templates/official-journal-of-iceland/Length of output: 744
Script:
#!/bin/bash # Check RejectScreen.tsx content echo "=== RejectScreen.tsx content ===" cat libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx echo -e "\n=== Rejected.ts form content ===" cat libs/application/templates/official-journal-of-iceland/src/forms/Rejected.tsLength of output: 3130
libs/application/templates/official-journal-of-iceland/src/screens/PublishingScreen.tsx (1)
15-15: Verify type definition for goToScreen propPlease ensure that
goToScreenis properly typed in theOJOIFieldBasePropsinterface.✅ Verification successful
goToScreen prop is properly typed and used consistently
The
goToScreenprop is correctly defined in the component hierarchy:
- It's defined in the
Propsinterface of theFormScreencomponent:type Props = { // ... goToScreen?: (screen: string) => void }
- It's properly inherited through
OJOIFieldBasePropswhich extendsFieldBaseProps, and is used consistently across multiple screen components:
- PublishingScreen.tsx
- SummaryScreen.tsx
- PreviewScreen.tsx
- OriginalScreen.tsx
- CommentsScreen.tsx
- AttachmentsScreen.tsx
- AdvertScreen.tsx
The prop is optional (marked with
?), type-safe, and follows the codebase's patterns.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if goToScreen is defined in the types # Expected: Should find the type definition with goToScreen # Search for the type definition ast-grep --pattern 'interface OJOIFieldBaseProps { $$$ goToScreen$_ $$$ }' # Backup: Search using ripgrep if ast-grep doesn't find it rg -A 5 'interface OJOIFieldBaseProps'Length of output: 123
Script:
#!/bin/bash # Let's try a broader search to find the type definitions and props # First, find all TypeScript files in the official-journal-of-iceland template fd -e ts -e tsx . libs/application/templates/official-journal-of-iceland # Then search for any interfaces or types that might contain goToScreen rg -A 10 "interface.*Props|type.*Props" libs/application/templates/official-journal-of-iceland # Also search for the actual usage of goToScreen to understand its context rg "goToScreen" libs/application/templates/official-journal-of-icelandLength of output: 65949
libs/application/templates/official-journal-of-iceland/src/components/property/Property.tsx (1)
6-6: Verify handling of ReactNode values in Text component.The Text component might not properly handle all possible ReactNode values. Consider adding type guards or documentation about supported value types.
libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts (1)
1-2: LGTM! Clean and specific imports.The imports follow best practices for tree-shaking by importing only the required function from @apollo/client.
libs/application/templates/official-journal-of-iceland/src/components/signatures/Additional.tsx (1)
Line range hint
20-25: Verify layout consistency after flex styling removal.The removal of flex styling from the Box component might affect the layout consistency. Consider if this change was intentional and verify that it doesn't break the layout in different viewport sizes.
libs/application/templates/official-journal-of-iceland/src/fields/Original.tsx (3)
18-20: LGTM: Consistent message key updatesThe message key updates are consistent with the namespace change and maintain proper localization practices.
3-3: Verify message namespace migration completenessThe change from 'attachments' to 'original' namespace looks good, but let's ensure this change is consistent across the codebase.
✅ Verification successful
Import change is correctly scoped and implemented
The change from 'attachments' to 'original' namespace is correctly implemented within the Official Journal of Iceland template only. This is a localized change where:
- The new
originalmessages are defined inlibs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts- The old
attachmentsnamespace continues to exist and is used by other components likeAttachments.tsxin the same template- Other templates continue using their own
attachmentsnamespaces independently🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining references to the old 'attachments' message namespace # to ensure complete migration # Search for any remaining references to the old namespace rg -l "attachments\.inputs\.fileUpload" --type ts --type tsx # Search for usage of the new namespace to confirm proper adoption rg -l "original\.fileUpload" --type ts --type tsxLength of output: 170
Script:
#!/bin/bash # Let's try a different approach to search for message imports and usages # Search for imports related to attachments messages rg -l "from.*['\"].*attachments['\"]" # Search for imports related to original messages rg -l "from.*['\"].*original['\"]" # Search for any usage of attachments.inputs or attachments.fileUpload rg "attachments\.(inputs|fileUpload)" # Search for any usage of original.fileUpload rg "original\.fileUpload"Length of output: 3496
25-25: Verify single file upload restriction impactThe explicit
multiple={false}constraint is appropriate for original document upload. However, let's verify this doesn't break existing functionality.✅ Verification successful
Setting multiple={false} is appropriate and safe
The explicit
multiple={false}constraint is correct for this use case. The findings show:
- The
InputFileUploadcomponent hasmultiple=trueas its default value- This file is for original document upload where single file selection is the intended behavior
- Setting
multiple={false}explicitly overrides the default and ensures the correct behavior🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for existing usages of InputFileUpload to ensure # this change doesn't conflict with other implementations # Search for other InputFileUpload usages ast-grep --pattern 'InputFileUpload $$$multiple={true}$$$'Length of output: 60
Script:
#!/bin/bash # Let's try a broader search for InputFileUpload usage rg "InputFileUpload" -A 2 -B 2 # Also search for import statements to understand component usage rg "import.*InputFileUpload"Length of output: 35231
Script:
#!/bin/bash # Let's check the InputFileUpload component definition to understand the multiple prop ast-grep --pattern 'interface InputFileUploadProps { $$$ multiple?: $_ $$$ }' # Also search for any usage of multiple prop in InputFileUpload rg "multiple.*=.*true" -A 2 -B 2Length of output: 3086
libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts (2)
8-8: LGTM: Well-typed callback parameterThe
onCompletedcallback is properly typed with TypeScript, maintaining type safety and reusability across different NextJS applications.
27-27: LGTM: Clean parameter additionThe
onCompletedparameter is properly destructured and follows React hooks best practices.libs/application/templates/official-journal-of-iceland/src/fields/CommunicationChannels.tsx (2)
14-14: LGTM: State management follows best practicesThe new state variable is properly typed and follows React hooks conventions.
32-32: Verify AddChannel component prop typesThe new defaultName prop has been added, but we should verify its type definition in the AddChannel component.
✅ Verification successful
Props are correctly typed for AddChannel component
The
defaultNameprop is properly typed as an optional string in the AddChannel component's Props interface:type Props = { defaultName?: string // ...other props }🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check AddChannel component prop types # Expected: defaultName should be typed as string | undefined ast-grep --pattern 'interface Props { $$$ defaultName?: string $$$ }'Length of output: 77
Script:
#!/bin/bash # Let's try to find the AddChannel component definition first rg -l "AddChannel" --type tsx # Then let's look at its content including Props interface rg "AddChannel|Props|interface" -A 5 --type tsxLength of output: 135
Script:
#!/bin/bash # Let's try without file type restriction fd "AddChannel" --extension tsx --extension ts # Then look for the content rg "AddChannel.*Props" -A 10Length of output: 294
Script:
#!/bin/bash # Now that we have the exact file, let's examine its content cat "libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx"Length of output: 3655
libs/application/templates/official-journal-of-iceland/src/screens/RejectScreen.tsx (1)
1-6: LGTM! Well-structured imports following best practices.The imports are properly organized and follow tree-shaking practices by importing specific components. TypeScript types are appropriately used.
libs/application/templates/official-journal-of-iceland/src/lib/messages/submitted.tsx (1)
15-19: LGTM! Verify message usage.The new message follows the established naming pattern and structure. The ID, default message, and description are clear and consistent with other messages in the file.
Let's verify where this new message is being used:
✅ Verification successful
Message is properly integrated and used
The new message
newApplicationis correctly implemented and actively used:
- Added in
submitted.tsxwith proper ID, default message, and description- Integrated in
Submitted.tsxcomponent as a button text- Part of a feature allowing users to create a new application after submitting one
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find components using the new message key # Expected: Components rendering this message should be found # Search for the message key or default message rg -l "ojoi\.application:submitted\.general\.newApplication|Ný umsókn" --type tsxLength of output: 111
Script:
#!/bin/bash # Let's try a different approach using ripgrep without file type filter # Search for the message key and default message rg -l "ojoi\.application:submitted\.general\.newApplication|Ný umsókn" # Also search for potential imports of this messages file rg -l "from.*messages/submitted"Length of output: 586
Script:
#!/bin/bash # Let's check the actual usage context in these files rg -A 2 -B 2 "ojoi\.application:submitted\.general\.newApplication|Ný umsókn" libs/application/templates/official-journal-of-iceland/src/screens/SubmittedScreen.tsx libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx libs/application/templates/official-journal-of-iceland/src/forms/Submitted.ts # Also check if this is a newly added message or if it existed before git log -p libs/application/templates/official-journal-of-iceland/src/lib/messages/submitted.tsxLength of output: 3495
Script:
#!/bin/bash # Let's check the actual usage of this message in the latest changes rg -A 5 -B 5 "newApplication" libs/application/templates/official-journal-of-iceland/src/screens/SubmittedScreen.tsx # Also check for any other potential usages in recent changes git log -p -S "newApplication" --since="2024-10-01"Length of output: 14001
libs/application/templates/official-journal-of-iceland/src/forms/Complete.ts (2)
Line range hint
1-8: LGTM! Clean import statements.The removal of unused imports (
buildCustomField,buildMultiField, andsummary) improves code maintainability and tree-shaking capabilities.
Line range hint
9-54: Verify the empty section configurations.All form sections have empty
childrenarrays. While this might be intentional if the content is added dynamically, it would be helpful to document this design decision.Consider adding a comment explaining why the sections are empty and how they get populated. For example:
export const Complete: Form = buildForm({ id: 'OfficialJournalOfIcelandAdvertOfIcelandApplication', title: 'Skilyrði', mode: FormModes.COMPLETED, renderLastScreenBackButton: true, renderLastScreenButton: true, + // Note: Section children are dynamically populated during form initialization children: [Let's verify if these sections are populated elsewhere:
✅ Verification successful
The search results show that this is a form with different states (Draft, DraftRetry, Rejected, Submitted, Complete) where:
- In Draft and DraftRetry states, these sections have children with custom fields
- In Complete, Rejected and Submitted states, these sections intentionally have empty children arrays
- The form sections are navigated via buttons in FormScreen.tsx
Let me verify if there's any dynamic population happening in Complete state:
Empty sections in Complete form are intentional and consistent with the application's design
Looking at the search results, I can see that this is a common pattern across the codebase where forms in
COMPLETEDmode typically have empty sections or minimal content. This is especially true for forms that serve as completion/confirmation screens. The empty sections in the Complete form appear to be intentional as they are used for navigation structure only, which is evidenced by:
- The same empty section pattern is used in the Submitted and Rejected forms
- The actual form content is handled in Draft/DraftRetry states where sections have children with custom fields
- The sections are referenced in FormScreen.tsx for navigation purposes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for any dynamic population of these form sections # Expected: Find references to these routes where the sections might be populated echo "Searching for section population..." rg -A 5 "Routes\.(REQUIREMENTS|ADVERT|ATTACHMENTS|PREVIEW|ORIGINAL|PUBLISHING)" \ --type ts \ --glob '!libs/application/templates/official-journal-of-iceland/src/forms/Complete.ts'Length of output: 26157
Script:
#!/bin/bash # Search for any dynamic population specific to Complete form rg -A 5 "FormModes\.COMPLETED|mode:\s*FormModes\.COMPLETED" --type tsLength of output: 30936
libs/application/templates/official-journal-of-iceland/src/screens/AdvertScreen.tsx (1)
23-23: Navigation prop addition looks goodThe addition of the
goToScreenprop aligns with the PR objectives and maintains consistency with other screen components.libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularSignature.tsx (2)
49-58: LGTM! Layout improvement using Box component.The Box wrapper with flex layout improves the component's positioning and alignment while maintaining the shared UI component usage pattern.
Line range hint
1-58: Consider browser compatibility for structuredClone.The code uses
structuredClonefor deep copying objects, which might not be supported in older browsers. Consider using a more widely supported alternative or ensuring proper polyfills are in place.Consider alternatives like:
const currentAnswers = JSON.parse(JSON.stringify(application.answers))libs/application/templates/official-journal-of-iceland/src/lib/messages/original.ts (3)
Line range hint
1-41: LGTM! Well-structured localization messages.The code follows best practices for internationalization:
- Uses
react-intl'sdefineMessagesfor type-safe message definitions- Includes descriptive IDs with proper namespacing
- Provides helpful descriptions for translators
25-26: Improved upload instructions and simplified messaging.The changes enhance clarity by:
- Providing more specific upload instructions for scanned copies and digitally signed documents
- Simplifying the file type information
- Using a more concise button label
These improvements align well with the PR's UI enhancement objectives.
Also applies to: 31-31, 36-36
7-7: Verify terminology change impact.The change from "Frumgögn" to "Frumrit" appears to be a terminology update. While the change itself looks good, we should ensure consistency across the application.
Also applies to: 18-18
✅ Verification successful
Terminology change is consistent across the codebase
The search results confirm that:
- The old term "Frumgögn" is not present anywhere in the codebase
- The new term "Frumrit" is consistently used across all relevant files including:
- Application templates
- API domain mappings
- Client configurations
- Message files
The terminology change appears to have been completely and consistently implemented.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining instances of the old term to ensure complete migration # Expected: No instances of "Frumgögn" remain in the codebase echo "Searching for any remaining instances of the old term..." rg "Frumgögn" --type ts --type tsxLength of output: 195
Script:
#!/bin/bash # Let's try a more comprehensive search without file type restrictions # and handle special characters properly echo "Searching for any remaining instances of the old term..." rg -i "frumg[öo]gn" # Also search for the new term to understand its usage echo -e "\nSearching for the new term..." rg -i "frumrit"Length of output: 4211
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveComitteeMember.tsx (1)
Line range hint
9-17: LGTM: Strong TypeScript implementation.The component demonstrates proper TypeScript usage with well-defined prop types and proper typing throughout the implementation.
libs/application/templates/official-journal-of-iceland/src/forms/Rejected.ts (1)
24-53: Verify the purpose of empty sectionsMultiple sections are defined with empty children arrays. Please confirm if this is intentional or if these sections should contain fields for viewing the rejected application's data.
✅ Verification successful
Empty sections are intentional in rejected application state
After analyzing all form states in the codebase, I can confirm that empty sections in the Rejected form state are intentional. This is a consistent pattern across different application states:
- In the Draft/DraftRetry state, sections contain interactive components for data input
- In the Rejected state, sections are kept empty as they are read-only, with only the rejection information shown in the REJECTED section
- Similar empty sections pattern is found in Complete and Submitted states
- The empty sections serve as navigation structure while the actual content is shown in the state-specific section (e.g., RejectScreen component for rejected state)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if these sections have content in other form states ast-grep --pattern 'buildSection({ id: Routes.$_(REQUIREMENTS|ADVERT|ATTACHMENTS|PREVIEW|ORIGINAL|PUBLISHING), $$$ children: [$$$], })'Length of output: 143
Script:
#!/bin/bash # Let's try a different approach to find section definitions in form files fd "\.ts$" libs/application/templates/official-journal-of-iceland/src/forms -x rg -l "buildSection" # Then let's examine the content of these files fd "\.ts$" libs/application/templates/official-journal-of-iceland/src/forms -x cat {} \;Length of output: 13744
libs/application/templates/official-journal-of-iceland/src/lib/messages/involved-parties.ts (2)
Line range hint
1-54: Well-structured internationalization implementation.The file follows best practices for reusability and maintainability:
- Proper use of
defineMessagesfor type-safe i18n- Well-organized message grouping
- Comprehensive descriptions for translators
- Proper TypeScript exports enabling effective tree-shaking
13-13: Verify UX flow consistency with the updated message.The message change from institution selection to legal entity selection for advertisements indicates a significant UX flow change. While the new message is clear, we should verify that this aligns with the updated UI flow and user permissions model.
✅ Verification successful
Let me gather more information about the involved parties component and its usage.
Based on the gathered information, I can now provide a final response:
The message change correctly reflects the legal entity selection flow
The updated message accurately describes the user experience for accounts with multiple legal entity access. This is verified by:
- The codebase shows proper handling of legal entity (
subjectType === 'legalEntity') user types- The auth system supports switching between legal entities via
switchUserfunctionality- Multiple components check for legal entity access using
userInfo.profile.subjectTypeThe message change is consistent with the existing authentication and authorization model, and no issues were found in the implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for related components and permission checks that might need updates # Look for components using these messages rg -A 5 "ojoi\.application:original\.general\.intro" # Check for permission/access related code ast-grep --pattern 'const $_ = useAuth()'Length of output: 7315
Script:
#!/bin/bash # Check for components using the involved parties messages rg -l "involved-parties" # Look for components that might be handling legal entity selection ast-grep --pattern 'interface $_ { $$$ legalEntity$_: $_ $$$ }' # Search for legal entity related components rg -A 5 "legalEntity"Length of output: 26185
libs/application/templates/official-journal-of-iceland/src/components/signatures/RemoveRegularMember.tsx (1)
Line range hint
15-58: Implementation looks good!The component is well-structured with:
- Proper TypeScript types
- Clear separation of concerns
- Effective use of hooks
- Reusable implementation
libs/application/templates/official-journal-of-iceland/src/lib/constants.ts (1)
39-39: LGTM: New route constant follows conventionsThe addition of
REJECTEDto the Routes enum aligns with the PR objective of implementing rejected state functionality.libs/application/templates/official-journal-of-iceland/src/components/input/OJOISelectController.tsx (2)
81-81: LGTM!The onSelect handler correctly implements the new signature by passing both label and value.
Line range hint
1-83: Component follows library coding guidelines.✅ Reusable across NextJS apps
✅ Proper TypeScript usage for props and types
✅ Tree-shaking friendly implementationlibs/application/templates/official-journal-of-iceland/src/components/signatures/Committee.tsx (2)
1-1: Verify bundle impact of island-ui components.The Stack component import looks good, but let's verify it supports tree-shaking to minimize bundle size.
Line range hint
56-65: Consider using a stable key for committee members.While the Stack implementation improves layout structure, using array indices as keys could lead to unexpected behavior if items are reordered or removed. Consider using a unique identifier from the member data if available.
- key={index} + key={member.id} // Assuming member has an id fieldLet's verify if member objects have a unique identifier:
libs/application/templates/official-journal-of-iceland/src/lib/types.ts (2)
15-15: LGTM! The typeName field addition is well-structured.The new field follows the established pattern and naming conventions while maintaining type safety.
15-15: Consider whether typeName should be required.The field is added to InputFields but not to RequiredInputFieldsNames. If this is a required field for advertisements, consider adding it to RequiredInputFieldsNames with an appropriate Icelandic label.
Let's check if typeName is used as a required field in the codebase:
libs/application/templates/official-journal-of-iceland/src/lib/messages/attachments.ts (1)
Line range hint
1-70: Well-structured localization messages implementationThe code follows best practices for reusability and type safety:
- Properly uses TypeScript with
defineMessages- Exports named constants for tree-shaking
- Organizes messages in a hierarchical structure for reuse across components
libs/application/templates/official-journal-of-iceland/src/fields/Comments.tsx (3)
19-21: LGTM: Well-defined TypeScript type!The Props type is properly defined with TypeScript, correctly extending the base props and marking the new prop as optional.
23-23: LGTM: Component signature maintains backward compatibility!The default value of true for canAddComment ensures existing usage won't break.
Line range hint
1-91: LGTM: Complies with library coding guidelines!The component follows all required guidelines:
- ✓ Reusable through clear props interface
- ✓ Proper TypeScript usage
- ✓ Effective tree-shaking with specific imports
libs/application/templates/official-journal-of-iceland/src/lib/messages/general.ts (2)
12-19: LGTM! Status labels follow best practicesThe new status labels are well-structured, properly typed, and follow the established naming conventions. They maintain consistency with the existing messages and support the new state management features.
Line range hint
1-28: LGTM! File complies with coding guidelinesThe file demonstrates excellent compliance with the coding guidelines for
libs/**/*:
- Uses TypeScript effectively with proper type definitions via react-intl
- Maintains reusability through modular message definitions
- Supports effective tree-shaking with clean exports
libs/application/templates/official-journal-of-iceland/src/components/signatures/Regular.tsx (2)
59-72: LGTM: Improved layout structure using Stack componentThe change from Box to Stack with proper spacing and dividers improves the visual hierarchy and maintainability of the member list.
61-61:⚠️ Potential issueVerify browser compatibility of Array.prototype.at()
The
.at()method is a relatively new addition to JavaScript. Ensure proper polyfilling or consider using traditional array indexing for broader browser support.Consider using traditional array indexing for better compatibility:
-const member = signature.members?.at(memberIndex) +const member = signature.members?.[memberIndex]libs/application/templates/official-journal-of-iceland/src/lib/messages/summary.ts (1)
68-87: LGTM! New message definitions follow consistent patterns.The new properties for communication channels and fast track options are well-structured and maintain consistency with existing patterns. Each entry includes appropriate ID namespacing, clear default messages, and helpful descriptions.
libs/application/templates/official-journal-of-iceland/src/components/signatures/Signatures.css.ts (3)
3-3: LGTM! Good use of constants for consistency.The import of
OJOI_INPUT_HEIGHTfrom constants helps maintain consistency across the application and supports effective tree-shaking.
63-63: LGTM! Simplified layout logic.The removal of conditional flex direction in favor of a consistent column layout improves maintainability and reduces complexity.
112-118: LGTM! Enhanced button styling with proper alignment.The updated styling for the remove button follows consistent design patterns:
- Uses the shared input height constant
- Implements proper border styling
- Centers content both horizontally and vertically
libs/application/templates/official-journal-of-iceland/src/hooks/useUpdateApplication.ts (3)
5-6: LGTM! Well-structured imports following best practices.The imports are properly organized with types separated from values, enabling effective tree-shaking.
Also applies to: 13-14
38-38: LGTM! Clear and consistent mutation hooks setup.The mutation hooks follow Apollo Client best practices with proper TypeScript typing for loading states and error handling.
Also applies to: 42-47
114-124: LGTM! Consistent and well-structured return object.The new states and methods are properly integrated into the return object, maintaining type safety and reusability across different NextJS applications.
libs/application/templates/official-journal-of-iceland/src/components/signatures/CommitteeMember.tsx (2)
Line range hint
1-24: LGTM! Well-structured imports and type definitions.The code follows best practices for reusability and type safety:
- Uses tree-shakeable imports
- Properly defines TypeScript types
- Maintains clear component interfaces
96-106: LGTM! Improved layout structure using Stack.The use of the Stack component from island-ui/core improves spacing management and reduces nested markup.
libs/application/templates/official-journal-of-iceland/src/components/form/FormScreen.tsx (1)
30-30: LGTM! Well-typed optional prop.The
goToScreenprop is properly typed as an optional function parameter, following TypeScript best practices.libs/application/templates/official-journal-of-iceland/src/components/communicationChannels/AddChannel.tsx (2)
13-13: LGTM: Type definition follows best practicesThe new optional prop
defaultNameis well-typed and maintains backward compatibility.
102-104: LGTM: Consistent state reset implementationThe name state reset is properly implemented alongside other state resets in the cancel action.
libs/application/templates/official-journal-of-iceland/src/screens/InvolvedPartyScreen.tsx (1)
76-107: LGTM! Well-structured UI implementation.The UI implementation follows good practices:
- Proper component composition with Box and Stack
- Clear error state handling
- Responsive layout with width="half"
- Reusable select component with proper props
🧰 Tools
🪛 Biome
[error] 104-104: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (2)
32-32: LGTM! Grammar correction in Icelandic text.The change from 'Afrita eldri mál' to 'Afrita eldra mál' improves grammatical accuracy.
81-81: LGTM! Improved placeholder guidance.The new placeholder text 'Heiti auglýsingar (án tegundar)' provides clearer guidance by explicitly stating that the advertisement title should be entered without its type. This change aligns well with the form's purpose and helps prevent user confusion.
libs/application/templates/official-journal-of-iceland/src/components/signatures/Chairman.tsx (1)
Line range hint
80-119: Well-structured layout implementationThe new flexbox layout is well-implemented with:
- Proper use of flex properties for responsive design
- Consistent spacing using gaps
- Logical grouping of related fields
libs/application/templates/official-journal-of-iceland/src/lib/messages/publishing.ts (3)
44-54: LGTM! Well-structured fast track messages.The new message definitions for fast track functionality are well-organized and provide clear context for translators through descriptive IDs and descriptions.
96-96: LGTM! Improved message conciseness.The updated placeholder text is more concise while maintaining clarity about its purpose.
Line range hint
1-113: LGTM! Follows library code guidelines.The file maintains:
- Type safety through TypeScript
- Reusable message definitions
- Proper tree-shaking support through static exports
libs/application/templates/official-journal-of-iceland/src/fields/Advert.tsx (2)
Line range hint
1-28: LGTM: Clean imports and hook setup.The imports and hook initialization follow React best practices and maintain proper TypeScript typing.
60-63: Verify handling of undefined values in title preview.Please ensure that
getAdvertMarkupproperly handles cases wherecurrentApplication.answers.advertmight be undefined.✅ Verification successful
getAdvertMarkupproperly handles undefined valuesThe implementation safely handles undefined values for all parameters:
- All parameters are marked as optional with
?in the type definition- The function uses conditional (ternary) operators to handle undefined cases, returning empty strings when values are not provided
- This matches the usage in
Advert.tsxwhere optional chaining is used with?.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for getAdvertMarkup implementation to verify null checks ast-grep --pattern 'function getAdvertMarkup($_) { $$$ }'Length of output: 61
Script:
#!/bin/bash # Search for getAdvertMarkup with different patterns and file extensions rg -g '*.{ts,tsx,js,jsx}' 'getAdvertMarkup' -A 5 # Also search for export declarations rg -g '*.{ts,tsx,js,jsx}' 'export.*getAdvertMarkup' -A 5 # Search for any file containing 'advert' in its name fd -g '*[aA]dvert*.{ts,tsx,js,jsx}'Length of output: 5088
Script:
#!/bin/bash # Let's check the implementation of getAdvertMarkup in utils.ts cat libs/application/templates/official-journal-of-iceland/src/lib/utils.ts | grep -A 15 "export const getAdvertMarkup"Length of output: 449
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.resolver.ts (2)
28-29: LGTM! Clean and consistent imports.The new type imports follow the established naming conventions and TypeScript best practices.
129-137: LGTM! Well-structured query implementation.The implementation follows best practices with proper typing, authentication, and separation of concerns. However, let's verify the error handling in the service layer.
✅ Verification successful
Let me gather more specific information about the error handling in the service layer.
Let me try one more search with a different pattern to locate the service implementation.
Let me try one final search to specifically locate the service implementation for getApplicationCase.
Based on the evidence gathered from the codebase, I can now provide a final response:
Error handling is properly implemented in the service layer
The implementation follows a robust error handling pattern where:
- The resolver delegates to the service layer
- The service layer uses try-catch blocks consistently
- Errors are propagated through the client service which includes proper logging
The error handling implementation aligns with the codebase's patterns, making it a safe and reliable implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify error handling in the service layer for getApplicationCase # Search for error handling patterns in the service implementation ast-grep --pattern 'getApplicationCase($_, $_) { try { $$$ } catch { $$$ } }' # Search for custom exceptions or error types rg -l "class.*Error extends" --type tsLength of output: 802
Script:
#!/bin/bash # Search for the service implementation of getApplicationCase ast-grep --pattern 'getApplicationCase($id, $user) { $$$ }' # Search for any error handling related to this specific service rg "class.*Error.*OJOIApplication" --type ts # Look for any throw statements in the service rg "throw new" -A 2 -B 2 --type ts | grep -C 4 "OJOIApplication"Length of output: 175
Script:
#!/bin/bash # Find the service file first fd "ojoiApplication.service.ts" # Then look for any error handling patterns in files related to OJOI rg "throw|catch|try" -A 2 -B 2 --type ts | grep -C 4 -i "ojoi" # Look for the service class implementation ast-grep --pattern 'class OJOIApplicationService { $$$ }'Length of output: 31354
Script:
#!/bin/bash # Search for the specific method implementation ast-grep --pattern 'getApplicationCase($id, $user) { $$$ }' # Also search for any error handling in the service file we found earlier rg "getApplicationCase|catch|throw" libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.service.tsLength of output: 325
libs/application/templates/official-journal-of-iceland/src/fields/Publishing.tsx (3)
Line range hint
56-77: LGTM! Robust category update handling.The category update logic is well-implemented with proper loading state management and cleanup.
155-161: LGTM! Clear fast track status feedback.The fast track alert implementation provides clear feedback to users about their submission status.
38-49: Verify timezone handling in date calculations.The date handling logic includes a check for submissions after 12:00, but this might need additional consideration for timezone differences.
Please verify:
- How the 12-hour check behaves across different timezones
- Whether the date calculations should use UTC
libs/application/templates/official-journal-of-iceland/src/components/signatures/RegularMember.tsx (1)
Line range hint
16-27: LGTM: Well-structured component with proper TypeScript usageThe component follows React best practices with proper prop typing and null handling.
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (2)
Line range hint
1-31: LGTM: Clean import organization and proper TypeScript usage.The imports are well-organized and the component properly defines its props using TypeScript, maintaining good type safety.
Also applies to: 32-32
Line range hint
32-167: Well-structured component with proper TypeScript implementation.The component demonstrates:
- Good separation of concerns
- Proper TypeScript usage
- Reusable design suitable for a library component
- Clear error handling and user feedback
🧰 Tools
🪛 Biome
[error] 105-105: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 144-144: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/clients/official-journal-of-iceland/application/src/lib/ojoiApplicationClient.service.ts (1)
19-20: LGTM: Type imports follow best practices.The new type imports maintain type safety and enable effective tree-shaking.
libs/api/domains/official-journal-of-iceland-application/src/lib/ojoiApplication.service.ts (2)
26-26: LGTM! Import statement follows TypeScript best practices.The import is correctly defined and necessary for type safety.
212-240: Verify service reusability across NextJS apps.Since this service is in the libs directory, let's ensure it's properly reusable.
✅ Verification successful
Service reusability is properly implemented
The service follows the correct architectural pattern for reusable libraries:
- It's properly exported through the module's barrel file (index.ts)
- It's integrated into the main API application as a feature module
- It follows the island.is domain module pattern with both service and client configurations
The service is currently used as an API backend service, which is a valid use case for libs directory modules. While it's not directly imported by multiple NextJS apps, it serves as a reusable API domain that can be consumed by any frontend through the GraphQL API.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if this service is imported by multiple NextJS apps # Expected: Multiple apps importing this service # Find NextJS apps importing this service rg -l "OfficialJournalOfIcelandApplicationService" apps/Length of output: 56
Script:
#!/bin/bash # Let's try a broader search to understand the usage pattern # First, let's check the module name in package.json cat libs/api/domains/official-journal-of-iceland-application/package.json # Then search for any imports of this module across the codebase rg -l "@island.is/api/domains/official-journal-of-iceland-application" apps/ # Also check if there are any direct references to the class name rg -l "OJOIApplicationService" apps/ # Let's also check the module's barrel file exports cat libs/api/domains/official-journal-of-iceland-application/src/index.tsLength of output: 578
Script:
#!/bin/bash # Let's check how this service is used in the API app cat apps/api/src/app/app.module.ts # Also check if there are any other potential consumers rg -l "OfficialJournalOfIcelandApplicationModule" apps/ # Check if there are any GraphQL/REST endpoints using this service rg "OfficialJournalOfIcelandApplication" apps/api/src/ -A 5Length of output: 23769
libs/application/templates/official-journal-of-iceland/src/lib/utils.ts (2)
16-16: LGTM!The import statement follows the proper convention for constants.
325-344: Verify the function usage in dependent components.According to the summary, this function is used in the Publishing and Summary components. Let's verify the implementation is compatible with these usages.
✅ Verification successful
Function implementation is compatible with all usages
The verification shows that
getFastTrackis used in two components as expected:
Summary.tsx: ExtractsfastTrackfrom the result using optional datePublishing.tsx: Uses the function twice, both times extractingfastTrackfrom the result with a new Date objectAll usages are compatible with the current implementation as they:
- Handle the optional date parameter correctly
- Access only the documented return properties (
fastTrack)- Pass valid Date objects as arguments
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for getFastTrack usage in the codebase echo "Searching for getFastTrack usage..." rg -A 5 "getFastTrack" --type ts --type tsxLength of output: 152
Script:
#!/bin/bash # Search for getFastTrack usage with ripgrep, handling TypeScript files echo "Searching for getFastTrack usage..." rg -A 5 "getFastTrack" --type typescript # Also search with ast-grep to catch any TypeScript/TSX imports and usages echo -e "\nSearching for getFastTrack imports and usages with ast-grep..." ast-grep --pattern 'import { $$$, getFastTrack, $$$ } from "$_"' echo -e "\nSearching for getFastTrack function calls..." ast-grep --pattern 'getFastTrack($_)'Length of output: 1141
libs/application/templates/official-journal-of-iceland/src/lib/dataSchema.ts (2)
50-50: LGTM!The addition of the optional
typeNamefield follows the schema's pattern and is properly typed.
Line range hint
1-1: Coding guidelines compliance verified.The file follows the coding guidelines for libs directory:
- ✅ Schemas and types are properly exported for reuse
- ✅ TypeScript is used effectively for type definitions
- ✅ Code is modular and can be tree-shaken
libs/application/templates/official-journal-of-iceland/src/lib/messages/error.ts (1)
67-67: LGTM! Consistent terminology and clear messaging.The changes maintain consistency by:
- Using "auglýsing" (advertisement) instead of "innsending" (submission)
- Keeping a consistent message structure across all error types
- Following the react-intl pattern for internationalization
These changes align well with the PR objectives for UI improvements.
Also applies to: 77-77, 107-107, 112-112, 117-117, 122-122
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (2)
Line range hint
247-291: Well-implemented UI enhancements!The new Property components for fastTrack and communicationChannels are well-structured with:
- Proper loading state handling
- Consistent use of Tag components
- Clean implementation of conditional rendering
Line range hint
1-291: Verify TypeScript types across the codebase.While the component is well-structured and reusable, let's ensure consistent type usage across related components.
🧰 Tools
🪛 Biome
[error] 133-133: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 134-134: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/components/htmlEditor/HTMLEditor.css.ts (2)
Line range hint
1-141: LGTM! Well-structured legend and warning system.The changes to the legend system are well-implemented:
- Reuses existing code through parameterization
- Provides a convenient shorthand for warnings
- Maintains consistent visual feedback
Also applies to: 143-800
142-142: Verify the impact of reduced editor height.The significant reduction in minimum height (from 200 to 100) might affect usability and create inconsistent experiences across different applications using this component.
Let's check if this component is used across other applications:
libs/clients/official-journal-of-iceland/application/src/clientConfig.json (2)
300-324: LGTM: Well-structured endpoint definition.The new endpoint follows REST conventions and maintains consistency with existing endpoints. The response schema is properly referenced and parameters are well-documented.
1031-1189: LGTM: Well-structured schema definitions with comprehensive documentation.The new schemas for MainCategory, Category, CommunicationStatus, Department, AdvertType, ApplicationCase, and GetApplicationCaseResponse are well-designed with:
- Consistent use of required fields
- Clear descriptions for properties
- Proper handling of relationships between entities
- Good examples where appropriate
libs/application/templates/official-journal-of-iceland/src/lib/OJOIApplication.ts (20)
1-1: Imports are appropriate and utilized correctlyThe imported functions
getValueViaPathandpruneAfterDaysare correctly used within the code, enhancing functionality and maintainability.
16-16: Importing necessary typesThe import of
InputFieldsandTemplateApiActionsensures proper type definitions and improves code clarity.
27-27: Addition of 'REJECTED' state enhances application flowIntroducing
REJECTEDtoApplicationStatesallows the application to handle rejected cases effectively, aligning with the new features described in the PR.
35-53: Implementing dynamic application names improves user experienceThe
getApplicationNamefunction correctly generates dynamic names based on the application'stitleandtype, ensuring applications are easily identifiable.
59-59: Addition of 'EDIT' event enhances state transitionsIncluding
{ type: DefaultEvents.EDIT }inOJOIEventsand handling it in the state machine allows applicants to revise their submissions, increasing flexibility.
67-67: Assigning dynamic name function to application templateSetting the
nameproperty togetApplicationNameensures that the application title reflects user-provided information dynamically.
124-129: Adding action cards improves status visibilityThe
actionCardwith a status tag in theDRAFTstate enhances user feedback by displaying the application's current status with appropriate labeling.
162-164: Transitions to 'REJECTED' state are correctly definedThe transitions for
[DefaultEvents.REJECT]have been added in relevant states, directing toApplicationStates.REJECTED. This ensures proper handling of rejections at various stages.Also applies to: 210-212, 258-260
173-178: Action card added to 'DRAFT_RETRY' state enhances UXIncluding an
actionCardin theDRAFT_RETRYstate provides users with clear status indications, improving the overall user experience.
184-184: Deletion permission updated in 'DRAFT_RETRY' stateThe
deletepermission for theAPPLICANTrole is set tofalsein theDRAFT_RETRYstate. Confirm that applicants should not delete applications at this stage.
205-205: Submission event correctly configured in 'DRAFT_RETRY' stateThe
[DefaultEvents.SUBMIT]transition ensures applicants can resubmit their application after edits, maintaining proper workflow.
227-232: Action card in 'SUBMITTED' state enhances clarityThe
actionCardwith a purple variant in theSUBMITTEDstate provides clear visual feedback on the application's submitted status.
238-238: Deletion permission updated in 'SUBMITTED' stateThe
deletepermission for theAPPLICANTrole is nowfalsein theSUBMITTEDstate. Verify that applicants are intended to be prevented from deleting submitted applications.
255-257: Handling 'EDIT' event allows post-submission revisionsThe transition for
[DefaultEvents.EDIT]directs submitted applications back toDRAFT_RETRY, enabling applicants to make necessary changes.
269-274: Action card in 'COMPLETE' state uses 'mint' variantThe
actionCardin theCOMPLETEstate utilizes amintvariant. Please confirm that'mint'aligns with the design system and is appropriate for indicating completion.
280-280: Deletion permission updated in 'COMPLETE' stateSetting
delete: falsefor theAPPLICANTrole in theCOMPLETEstate prevents deletion of completed applications. Ensure this aligns with expected behavior.
294-322: Implementation of 'REJECTED' state is comprehensiveThe new
REJECTEDstate is well-defined with appropriate metadata, action cards, lifecycle, and role permissions, ensuring rejected applications are managed correctly.
298-298: Confirm lifecycle duration for 'REJECTED' stateThe lifecycle is set to
pruneAfterDays(30)for theREJECTEDstate. Verify if 30 days provides sufficient time for applicants to review the rejection.
308-309: Role permissions in 'REJECTED' stateThe
APPLICANTrole hasread: 'all'anddelete: falsein theREJECTEDstate. Confirm that applicants should not delete or modify rejected applications.
316-319: Assignee role permissions in 'REJECTED' stateThe
ASSIGNEErole hasread: 'all'andwrite: 'all'permissions. Ensure this is intentional and aligns with expected responsibilities.
libs/api/domains/official-journal-of-iceland-application/src/models/applicationCase.response.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/hooks/useApplicationCase.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/hooks/useTypes.ts
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/CommunicationChannels.tsx
Show resolved
Hide resolved
libs/clients/official-journal-of-iceland/application/src/clientConfig.json
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Submitted.tsx
Show resolved
Hide resolved
…ub.com/island-is/island.is into feat/ojoi-application-additional-state
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
- apps/web/screens/OfficialJournalOfIceland/OJOISearch.tsx (0 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (9 hunks)
💤 Files with no reviewable changes (1)
- apps/web/screens/OfficialJournalOfIceland/OJOISearch.tsx
🧰 Additional context used
📓 Path-based instructions (1)
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
🪛 Biome
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx
[error] 131-131: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 132-132: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 171-171: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 172-172: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 202-202: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 203-203: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (2)
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (2)
7-10: LGTM: Clean imports and prop additions.The new imports and prop changes follow best practices for tree-shaking and TypeScript usage.
Also applies to: 17-18, 36-36
96-100: LGTM: Clean fast track implementation.The fast track calculation is implemented safely with proper date handling.
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx
Show resolved
Hide resolved
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx
Outdated
Show resolved
Hide resolved
…ub.com/island-is/island.is into feat/ojoi-application-additional-state
jonbjarnio
added
the
deprecated:automerge
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (1)
96-100: Add documentation for fast track logic.Consider adding a comment explaining the business logic behind fast track determination, as this appears to be a key feature for the application workflow.
+ // Determine if the application qualifies for fast track processing based on the requested date const requestedDate = application.answers.advert?.requestedDate const { fastTrack } = getFastTrack( requestedDate ? new Date(requestedDate) : new Date(), )
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
- libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (4 hunks)
- libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (9 hunks)
- libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (3 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (1)
Pattern
libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
🪛 Biome
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx
[error] 105-105: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 150-150: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx
[error] 131-131: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 132-132: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 177-177: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 178-178: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 208-208: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 209-209: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (9)
libs/application/templates/official-journal-of-iceland/src/lib/messages/advert.ts (3)
37-37: LGTM: Grammar correction in Icelandic.The message update from 'Afrita eldri mál' to 'Afrita eldra mál' improves the grammar.
86-86: LGTM: Improved user guidance.The updated placeholder provides clearer instructions by explicitly stating that the advertisement title should exclude the type.
21-25: Verify ICU message format usage.The new
sectionWithAbbreviationmessage uses the ICU message format with a placeholder{x}. The implementation looks good, but let's ensure it's used correctly in the components.✅ Verification successful
ICU message format is correctly implemented and used
The
sectionWithAbbreviationmessage is properly used in both Preview.tsx and Summary.tsx components, where it correctly passes the 'x' parameter with value 'a' using the ICU message format. The implementation is consistent across both usage locations and matches the message definition.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of sectionWithAbbreviation message # Test: Search for components using this message to ensure proper ICU format usage rg -l "sectionWithAbbreviation" --type ts --type tsxLength of output: 80
Script:
#!/bin/bash # Search for sectionWithAbbreviation usage in all text files rg "sectionWithAbbreviation" -t tsLength of output: 596
Script:
#!/bin/bash # Check the context of usage in Preview.tsx and Summary.tsx rg "sectionWithAbbreviation" -B 2 -A 2 libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsxLength of output: 1371
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx (3)
16-29: LGTM! Well-organized imports following best practices.The new imports are logically grouped and maintain good modularity by centralizing validation schemas and utilities.
Line range hint
32-48: LGTM! Well-structured component with proper TypeScript usage.The component follows best practices:
- Proper TypeScript prop typing
- Appropriate loading state handling
- Good separation of concerns with hooks
49-57: Consider performance optimization for validation checks.The validation checks could benefit from memoization to prevent unnecessary recomputation on each render.
libs/application/templates/official-journal-of-iceland/src/fields/Summary.tsx (3)
7-10: LGTM: Import and prop additions are well-structured!The new imports and prop additions are properly typed and align well with the new features being implemented.
Also applies to: 17-18, 36-36
276-277: Improve readability of channels length check.The condition can be written more clearly to express the intent.
- currentApplication.answers.advert?.channels?.length !== 0 && ( + currentApplication.answers.advert?.channels?.length > 0 && (
131-133:⚠️ Potential issueUse optional chaining for cleaner code.
The code can be simplified using optional chaining operator.
- setSubmitButtonDisabled && setSubmitButtonDisabled(false) - goToScreen && goToScreen(route) + setSubmitButtonDisabled?.(false) + goToScreen?.(route)Also applies to: 177-179, 208-210
🧰 Tools
🪛 Biome
[error] 131-131: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 132-132: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
libs/application/templates/official-journal-of-iceland/src/fields/Preview.tsx
Show resolved
Hide resolved
What
New features
Improvements
Checklist:
Summary by CodeRabbit
Summary by CodeRabbit
New Features
RejectScreencomponent for handling rejected applications.goToScreenprop across multiple components for enhanced navigation.Improvements
Bug Fixes
Documentation