Web / Local Marketplace
TaskAround Website
An unpublished Nuxt website project for TaskAround, connecting people who need help with local service providers.
- Context
- TaskAround / Algonova repository
- Source Code
- Public source
Engineering scope
Engineering Scope
Stack: Vue 3 · Nuxt 4 · TypeScript · Internationalization
Inspect the source ↗TaskAround Website 2.0 is a Nuxt and Vue website for a local-services marketplace. My contribution covered service discovery and two separate onboarding journeys: posting a task and becoming a service provider, or Tasker.
An unpublished frontend prototype. Task and provider submissions are simulated; automated tests remain on the project roadmap.
01 / Discovery routes
Use routes for city, category and provider discovery
A visitor may arrive at a city, category or individual provider rather than the homepage. If this context exists only in local component state, direct links cannot reproduce the same discovery view.
I organized discovery around Nuxt routes for cities, categories and provider profiles. Shared layouts and components provide the surrounding interface, with middleware supplying city context and separate locale resources holding translations.
The middleware currently recognizes one city and supplies a default. Adding cities requires extending that behavior and checking its interaction with localized routes.
02 / Task creation
Keep a task draft across form steps
Task details, location, schedule and contact information do not fit naturally into one short form. Splitting them across components can lose data when users move backwards.
I gave the task wizard one reactive NewTask draft and used a computed selector to choose the current step. KeepAlive preserves step instances, while next-step payloads update the shared draft. I added an isSubmitting guard to prevent repeated submissions within the active flow.
KeepAlive preserves step instances, so their local state must remain consistent with the parent draft. The submit handler is currently simulated; the implemented flow covers form progression and submission feedback.
03 / Provider onboarding
Give providers a separate onboarding flow
A customer describes a task; a provider supplies experience, motivation and service information. Forcing both journeys into the same form would produce conditional fields unrelated to one of those goals.
I built a separate six-step provider wizard around a typed PartnerApplication model. Each step supplies partial updates, while shared layout, translation and progress components avoid duplicating the surrounding interface.
Separate flows repeat some navigation code but keep their fields and types easier to understand. Shared layout and progress components provide reuse without coupling a customer request to a provider application.
04 / API integration
Centralize public API access
Embedding remote endpoint construction and service setup in every discovery page would couple rendering to environment configuration and repeat request code.
I kept public API calls in usePublicApi, using runtime configuration to construct endpoints and useFetch to load listings and tasks. Client plugins handle browser-specific service setup, leaving pages focused on rendering and interaction.
Runtime configuration keeps deployment details out of page components. Connecting the mocked wizard submissions remains separate work from these public listing and task-fetching helpers.
Evidence & further reading