Skip to content

v1.0.0

No due date 0% complete

After 8 years of censusapi, a majorly improved v1.0.0 is on the horizon. Work will begin after v0.9.0 is published on CRAN.

When the package was created in 2016, much of the current Census Bureau API functionality and the vast majority of the current data endpoints did not yet exist. It is time to modernize the package to reflect the current state of the …

After 8 years of censusapi, a majorly improved v1.0.0 is on the horizon. Work will begin after v0.9.0 is published on CRAN.

When the package was created in 2016, much of the current Census Bureau API functionality and the vast majority of the current data endpoints did not yet exist. It is time to modernize the package to reflect the current state of the API, be more flexible to future API functionality like additional metadata, and reflect modern R nomenclature standards.

Additional internal improvements will take advantage of newer R functionality like the httr2 package and some package development standards upgrades.

Key planned changes include:

Internal upgrades

  • Upgrade from retrieving data using httr to httr2. The package functions will be almost entirely rewritten to take advantage of httr2 and other internal improvements and efficiencies.
  • Require R >= 4.1 (released in 2021) to use the native R pipe in function code.

User-facing upgrades

  • Standardize and simplify function names to snake_case. getCensus() becomes get_census(), listCensusApis() becomes list_apis().
  • Split metadata retrieval function listCensusMetadata() into list_variables(), list_geographies(), list_values(), list_groups(). When the package was first written, only simple geography and variable metadata existed. The current mega-function is now overly complicated for users, unwieldy and inflexible for development, and not future-proof. Separate functions will be much simpler to use and provide better functionality.

The release will come with thorough documentation explaining any changes and perhaps a webinar. Old function names will continue to be available for a long period of time (a year?) so that old user code does not break. Messages in the console will recommend that users migrate to the new function names. The internal code improvements should just provide performance upgrades, no changes that affect users.

Feedback on the roadmap is welcomed in the discussion.