[GSoC] WiFi Login Pages Modernization

[nemesifier]

Official thread for this GSoC idea, ask questions and announce your interest here.

[prathmeshkulkarni-coder]

Hi @nemesifier , actually i am working on login page proposal. I make a repo of structure of client/component and I am thinking of turning .js files to .jsx file for easy code read and future upgrade . Are you open for it or I keep it to .js ??

[nemesifier]

If you could spend a few extra minutes articulating your question properly I may be able to understand, I only understood your want to turn JS some files into JSX and I don't have enough information in weighting pros and cons to give you a response.

What's the motivation behind these change? What are the benefits? What are the disadvantages?
Which files would be turned from JS to JSX? Apart from the extension renaming, is any other change required to the code?

[PRoIISHAAN]

Hi, i am interested in working on this, what all changes do you mean by modernisation, I already have a pr for upgrading to react 18, should we also convert our class based cmponents to functional components and all other migration from the legacy react code to the new code format?

[nemesifier]

@PRoIISHAAN did you read the WiFI Login Pages Modernization idea?

[KumarMunesh12]

Hi Iam Munesh Kumar. I want to contribute to this GSoC 26 project; I have a strong foundation in React.js and Node.js. I start with this one [feature] Automate generation of client/test-translation.json from .po files #902. Guide me more about this feature. Which library can I use gettext-parser or po2json for this one?

[nemesifier]

This question is off-topic here. GSoC related questions here only please.
Use the dev chat for questions related to specific issues like the one you cited.

[kankaa16]

Hi @nemesifier !
I've been going through the codebase to get familiar with codebase and noticed that the client/components/status/status.js file handled multiple things at once. Since you already proposed about the surgical+iterative refactor earlier,I found out the following issues;

1). The Status component manages authentication, usage monitoring, ui rendering, subscription period logic & session fetching. All these concerns together makes testing difficult.

2). Refactor componentDidMount : componentDidMount logic is quite confusing as it handles token validation, captive portal login, logout, redirect logic and cookie logic. The nested checks makes it harder to debug and may introduce bugs.

3). Repeated RADIUS session requests is called at multiple times, and current structure makes it harder to ensure consistency.

4). Component Modularity : The status.js file currently mixes ui rendering logic with session management and networking and even in captive portal sync logic. This also increases difficulty while testing individual components.

==My initial approach for the execution==

1). Extract helper functions for better flow
2). Reduce the complexity inside componentDidMount by making separate methods
3).Group related modules like centralizing the session refresh logic into a helper function, etc
4). Improve readability without change in behaviour.

Does this approach align with the issue, or shall I work in a different direction?
Happy to wait for the feedback before starting!

[nemesifier]

The main goal is to increase maintainability. Any pattern that react allows to separate things into different responsibilities which are implemented and tested separately is welcome.

[prathmeshkulkarni-coder]

Hey @nemesifier ,

To improve maintainability and allow for independent unit testing, I propose moving from a monolithic structure to a decentralized Service-Hook-Component approach:

• Centralized API Client (Axios): Replace scattered axios calls with a centralized utils/api-client.js instance.

  Benefit: Standardizes auth headers, language headers, and global error interceptors (e.g., auto-logout on 401) in one place.

• Service Layer (Pure JS): Extract complex business logic (e.g., RFC 8908 parsing, RADIUS usage calculations) into framework-agnostic JS modules.

  Benefit: 100% testable with pure Jest; logic remains decoupled from the React lifecycle.

• Logic Separation (Custom Hooks): Use "headless" hooks (e.g., useRadiusSessions, useCaptivePortal) to encapsulate all state and side effects.

  Benefit: Components become simple UI wrappers; logic can be verified independently using react-hooks-testing-library.

• Compound Components: Decompose massive views into smaller, specialized sub-components (e.g., <Status.Usage />, <Status.Table />).

  Benefit: Eliminates prop-drilling and allows features to be developed or modified in isolation without touching the main orchestrator.

Does this "Service-Hook-Component" architecture align with the project's long-term maintainability goals?