• Recent
  • Tags
  • Unsolved
  • Solved
  • MagicMirror² Repository
  • Documentation
  • 3rd-Party-Modules
  • Donate
  • Discord
  • Register
  • Login
MagicMirror Forum
  • Recent
  • Tags
  • Unsolved
  • Solved
  • MagicMirror² Repository
  • Documentation
  • 3rd-Party-Modules
  • Donate
  • Discord
  • Register
  • Login
A New Chapter for MagicMirror: The Community Takes the Lead
Read the statement by Michael Teeuw here.

Any plan to replace "request" and "moment"?

Scheduled Pinned Locked Moved Unsolved Feature Requests
61 Posts 8 Posters 22.4k Views 8 Watching
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • 0 Offline
    0m4r Module Developer @sdetweil
    last edited by Aug 29, 2021, 1:48 PM

    @sdetweil @sdetweil I am not convinced about both of your points of view. I mean technically yes.

    But… looking into the modules themselves, they are solely made to work with the MagicMirror code base (99% of the cases)
    What is the point to bloat the size of the installation with the same node module installed over and over again? when on, “global” can be used and relied upon? (well, yeah, I agree, “this situation” is one reason for it!). But why trade-off convenience over complexity?

    I see it as a part of the Magic Mirror ecosystem, provide some common “code” to be used by everyone to both ease the development and the set-up of it.

    As mentioned in the other thread, old legacy modules will probably stop working - forking them or re-doing them will fix them. This not only pushes forward the advancement of the whole MagicMirror tech stack, but it may strengthen the community and really push it to hold together and upgrade, modernize the code of the modules.

    bottom line, nobody says it is going to be easy, but it is a big opportunity.

    https://github.com/0m4r

    S 1 Reply Last reply Aug 29, 2021, 2:27 PM Reply Quote 0
    • S Offline
      sdetweil @0m4r
      last edited by Aug 29, 2021, 2:27 PM

      @0m4r said in Any plan to replace "request" and "moment"?:

      What is the point to bloat the size of the installation with the same node module installed over and over again

      it is NOT installed over and over

      npm install start with the module folder and says

      is it here?   
         no   
           look in the parent folders, 1 by 1, looking for a node_modules folder
             is it there?
                yes, stop
         yes, 
           stop. 
      

      so it will only be installed once…

      in the near term with all the old modules ‘assuming’ is was installed,
      it’ll have to be installed in the MM/node_modules (but only once)

      Sam

      How to add modules

      learning how to use browser developers window for css changes

      0 1 Reply Last reply Aug 29, 2021, 2:45 PM Reply Quote 1
      • 0 Offline
        0m4r Module Developer @sdetweil
        last edited by Aug 29, 2021, 2:45 PM

        @sdetweil yeah, I guess, I was not clear enough. And I think we are saying the same thing.

        Installing “request” in the MM root folder solves the problem, and this is how I do run my magic mirror from the development branch at this very moment.

        What I mean is that if the module is removed from the “MM/node_modules” folder (the last “parent” level for all modules), every single module will most likely need to install it on its own node_modules folder. This is where I meant it may blow up the size of the MM installation (modules included!)

        I hope this clarifies my prev post :)

        https://github.com/0m4r

        S 1 Reply Last reply Aug 29, 2021, 3:13 PM Reply Quote 0
        • S Offline
          sdetweil @0m4r
          last edited by Aug 29, 2021, 3:13 PM

          @0m4r said in Any plan to replace "request" and "moment"?:

          What I mean is that if the module is removed from the “MM/node_modules” folder (the last “parent” level for all modules), every single module will most likely need to install it on its own node_modules folder. This is where I meant it may blow up the size of the MM installation (modules included!)

          yeh, you have NO idea how big other stuff is already…

          but, this is the design… there is virtual memory, and paging and … to offset these

          now, remember, we are NOT making an installable bundle from all this, just a runtime layout

          Sam

          How to add modules

          learning how to use browser developers window for css changes

          1 Reply Last reply Reply Quote 0
          • B Offline
            BKeyport Module Developer @0m4r
            last edited by BKeyport Aug 30, 2021, 3:30 AM Aug 30, 2021, 3:21 AM

            God, the alternatives to moment are head spinning. I don’t understand 'em, and can’t even get basic functions to work right within jsfiddle.net (Example: Date1 <= Date2 crashes jsfiddle)

            For now, I’ve added package.json to both modules, and if needed, will update my install instructions.

            The "E" in "Javascript" stands for "Easy"

            1 Reply Last reply Reply Quote 1
            • M Offline
              MMRIZE
              last edited by Aug 31, 2021, 6:25 AM

              For the moment, maybe luxon or date-fns could be the alternative. (And there are several other modules also.)

              However, After releasing TC39’s new proposal (currently stage 3. https://tc39.es/ecma402/), Browsers and NodeJS will have the native features of handling dates. So I would recommend waiting.

              At this moment, native implementing moment’s features is not easy. Though Intl could handle many aspects of moment already, the unsolved big issue is, current Date and Intl features are still not perfect for localization, like weekOfYear, startdayOfWeek and so on. (Those will be solved by ECMA402)

              0 C 2 Replies Last reply Aug 31, 2021, 6:32 AM Reply Quote 0
              • 0 Offline
                0m4r Module Developer @MMRIZE
                last edited by Aug 31, 2021, 6:32 AM

                @mmrize agree to support native browser APIs, but I do also believe we cannot assume everyone is running an up-to-date system for their magic mirror.

                One idea could be to provide a wrapper module to abstract the “behind the scene” tool to manipulate dates, but it may turn out to be quite of an effort and limiting the module developer.

                https://github.com/0m4r

                1 Reply Last reply Reply Quote 0
                • C Offline
                  cowboysdude Module Developer @MMRIZE
                  last edited by Aug 31, 2021, 11:31 AM

                  @mmrize Well we all know how ‘browsers supporting’ all work out LOL

                  Some do…some don’t.

                  S 1 Reply Last reply Aug 31, 2021, 12:26 PM Reply Quote 0
                  • S Offline
                    sdetweil @cowboysdude
                    last edited by Aug 31, 2021, 12:26 PM

                    @cowboysdude AND for mm, the calendar date work is done OUTSIDE the browser in the node helper. soooooo, still need something

                    Sam

                    How to add modules

                    learning how to use browser developers window for css changes

                    1 Reply Last reply Reply Quote 0
                    • M Offline
                      MMRIZE
                      last edited by Aug 31, 2021, 1:13 PM

                      @cowboysdude @sdetweil
                      Fortunately, We need to consider only ‘Chromium’ and ‘node’ at most. (Firefox already implements almost-complete Intl features. For Safari… who cares.)
                      And in this case, Intl (and the Temporal in the future) suggests the STANDARD WAY how to handle date/time for L10N/I18N in Javascript environments(includes browsers and nodeJS). So I believe it has worthy looking inside.

                      Once (yesterday), I’ve tried to rewrite clock module and calendar module without momentjs or any other 3rd party library, only with Date and Intl.

                      The start was not so bad. I could rewrite many features with only Date and Intl.
                      Where I stuck was the showWeek config feature. It has to show the ordinal number of weeks of the year. To calculate ISOweek is not difficult. But in some areas, like the US. they never use the ISO system. damn!. To calculate the conventional US week number, additional pieces of information are needed. (read this.) Current Intl has not yet that feature. I’m waiting for Temporal and enhanced Intl releasing.

                      One solution might be to obtain additional information needed for conventional calculation from the user by configuration. At this point, I stopped rewriting. It needs to change config.js and that was not my first intention.

                      A usual solution might be to use 3rd party library like momentjs or luxon. It is easier.

                      However it’s good to read this from the momentjs (https://momentjs.com/docs/#/-project-status/future/) I agree to him, In the near future, native JS features Date, Intl, Temporal will be a standard.

                      S B 2 Replies Last reply Aug 31, 2021, 3:06 PM Reply Quote 0
                      • 1
                      • 2
                      • 3
                      • 4
                      • 5
                      • 6
                      • 7
                      • 3 / 7
                      3 / 7
                      • First post
                        24/61
                        Last post
                      Enjoying MagicMirror? Please consider a donation!
                      MagicMirror created by Michael Teeuw.
                      Forum managed by Sam, technical setup by Karsten.
                      This forum is using NodeBB as its core | Contributors
                      Contact | Privacy Policy